takanabe ( Takayuki Watanabe )

Takayuki Watanabe takanabe Cookpad Inc. Tokyo, Japan https://takanabe.tokyo Takayuki Watanabe (渡辺喬之) / SWE in Site Reliability Engineering. I use Ruby, Golang and AWS to build systems and software products.

repos

gists

followers

following

takanabe/github-actions-automate-projects 18

GitHub Actions adding GitHub Issues & Pull requests to the specified GitHub Project column automatically ♻️

takanabe/git-quiz 12

Quizzes for git practice

takanabe/fluent-plugin-aurora-slowquerylog 6

A fluent plugin that collects AWS Aurora slow query logs with log_output=FILE option

mizuman/bootcamp 0

for bootcamp hackathon

ryotarai/cookpad-tech-kitchen-1 0

srendipity/srendipity-test 0

test

takanabe/activerecord-async-migrations 0

A gem for asynchronous database migrations for Rails apps

takanabe/active_model_serializers 0

ActiveModel::Serializer implementation and Rails hooks

takanabe/alfred-workflow-url-craft 0

A workflow that transforms a url into new one that allows some formats such as "Github Flavored Markdown link" or "shorten url" and so on.

takanabe/amazon-kinesis-client-ruby 0

A Ruby interface for the Amazon Kinesis Client Library. Allows developers to easily create robust application to process Amazon Kinesis streams in Ruby.

fork takanabe/traefik

The Cloud Native Edge Router

https://traefik.io

traefik/traefik takanabe/traefik

fork in 5 days

startedgoogle/ko

started time in 9 days

startedamzn/awsssmchaosrunner

started time in 13 days

startedmercari/production-readiness-checklist

started time in 14 days

PR opened awsdocs/aws-cloudformation-user-guide

Update aws-properties-apitgateway-stage-methodsetting.md

According to https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html, ThrottlingBurstLimit is defined as follows:

In API Gateway, the burst limit corresponds to the maximum number of concurrent request submissions that API Gateway can fulfill at any moment without returning 429 Too Many Requests error responses.

the burst limit does not define the maximum number of requests per second but at any moment . This means API Gateway returns 429 when it receives more requests during a millisecond time-window than the value of ThrottlingBurstLimit. So, the current explanation of ThrottlingBurstLimit is not accurate and a replacement with accurate documents make sense.

Issue #, if available:

Description of changes:

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

+2 -2

1 commit in takanabe/aws-cloudformation-user-guide/tree/patch-1 awsdocs/aws-cloudformation-user-guide/tree/master

0 comment

1 changed file

pr created time in 14 days

push eventtakanabe/aws-cloudformation-user-guide

Takayuki Watanabe

commit sha 58fd262e0d809f13c14cbb727395953f22b037f7

Update aws-properties-apitgateway-stage-methodsetting.md According to https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html, `ThrottlingBurstLimit` is defined as follows: >In API Gateway, the burst limit corresponds to the maximum number of concurrent request submissions that API Gateway can fulfill at any moment without returning 429 Too Many Requests error responses. the burst limit does not define the maximum number of requests **per second** but **at any moment** . This means API Gateway returns 429 when it receives more requests during a millisecond time-window than the value of `ThrottlingBurstLimit`. So, the current explanation of `ThrottlingBurstLimit` is not accurate and a replacement with accurate documents make sense.

view details

push time in 14 days

fork takanabe/aws-cloudformation-user-guide

The open source version of the AWS CloudFormation User Guide

awsdocs/aws-cloudformation-user-guide takanabe/aws-cloudformation-user-guide

fork in 14 days

PullRequestReviewEvent

startedcrossplane/crossplane

started time in a month

startedaws/aws-controllers-k8s

started time in a month

startedkubernetes-monitoring/kubernetes-mixin

started time in a month

push eventanoma-inc/amplify-js

push time in a month

push eventanoma-inc/amplify-js

Takayuki WATANABE

commit sha 0399f0ea87cb778d0b9e25a0d8a44aba71f57acd

Remove files and directories at root

view details

Takayuki WATANABE

commit sha 4ea82ad053e766b50476d55d87c18c6f5031de5c

Move aws-amplify package to root

view details

Takayuki WATANABE

commit sha 55681f2381a4930e6fac0adb51756ff3afddd5b9

Remove unused packages

view details

Takayuki WATANABE

commit sha 9a934db50b7ddc983c48cea07168f4d261193948

Place all files for aws-amplify at the root (mv aws-amplify/* ./)

view details

push time in a month

startedvercel/swr

started time in a month

fork takanabe/amplify-js

A declarative JavaScript library for application development using cloud services.

https://docs.amplify.aws/lib/q/platform/js

aws-amplify/amplify-js takanabe/amplify-js

fork in a month

startedauth0/nextjs-auth0

started time in a month

startedvadimdemedes/ink

started time in a month

startedmizchi/next-boilerplate-20200727

started time in a month

startedCSFrequency/react-firebase-hooks

started time in a month

startedauth0/auth0-react

started time in a month

startedaws-amplify/amplify-js

started time in a month

starteddanielbayerlein/dashboard

started time in 2 months

startedunicodeveloper/awesome-nextjs

started time in 2 months

startedreact-dropzone/react-dropzone

started time in 2 months

startedstan-dev/pystan

started time in 2 months

startedserverless-nextjs/serverless-next.js

started time in 2 months

startedsummerwind/actions-runner-controller

started time in 2 months

startedpfnet-research/alertmanager-to-github

started time in 2 months

startedTablePlus/TablePlus

started time in 2 months

startedwinebarrel/spring_onion

started time in 2 months

issue closedtakanabe/github-actions-automate-projects

Remove opened scope

Hello, I'm using this action to automate the workflow of our team project organisations and I was wondering if you would consider removing this check. (linking you the issues.go file but could also be done in pull_requests.go)

https://github.com/takanabe/github-actions-automate-projects/blob/7e5d90f7e7f5f98c62c6c1f133c6206d8d254cf9/issues.go#L47

It forbid to use this action on other event such as labeled. I find it restrictive as it could have many such use than just opened and now it can be scoped at the event definition and do not require this additional check.

closed time in 2 months

ThomasVictoria

issue commenttakanabe/github-actions-automate-projects

Remove opened scope

@ThomasVictoria

Hi! I release v0.0.2 and you can use other events with the version!

ThomasVictoria

comment created time in 2 months

release takanabe/github-actions-automate-projects

v0.0.2

released time in 2 months

created tagtakanabe/github-actions-automate-projects

tagv0.0.2

GitHub Actions adding GitHub Issues & Pull requests to the specified GitHub Project column automatically ♻️

created time in 2 months

delete branch takanabe/github-actions-automate-projects

delete branch : accept-other-event

delete time in 2 months

push eventtakanabe/github-actions-automate-projects

Takayuki WATANABE

commit sha c5fc162f05bf44c57e48597c3fda45e6a02176da

Support all event actions in addition to "opened" action GitHub Actions supports conditional statement in its yaml file and users can manage the target event actions with the statement. ``` if: github.event_name == 'issues' && github.event.action == 'closed' ```

view details

Takayuki Watanabe

commit sha 5d004c140c65fa8b4ef3b18a38219ce680bce816

Merge pull request #21 from takanabe/accept-other-event Support all event actions in addition to "opened" action

view details

push time in 2 months

PR merged takanabe/github-actions-automate-projects

Support all event actions in addition to "opened" action

Background

GitHub Actions supports conditional statement in its yaml file and users can manage the target event actions with the statement.

if: github.event_name == 'issues' && github.event.action == 'closed'

Goal

Remove unnecessary conditions to detect event action types.

+0 -10

1 commit in takanabe/github-actions-automate-projects/tree/accept-other-event takanabe/github-actions-automate-projects/tree/master

0 comment

2 changed files

takanabe

pr closed time in 2 months

PR opened takanabe/github-actions-automate-projects

Support all event actions in addition to "opened" action

Background

GitHub Actions supports conditional statement in its yaml file and users can manage the target event actions with the statement.

if: github.event_name == 'issues' && github.event.action == 'closed'

Goal

Remove unnecessary conditions to detect event action types.

+0 -10

1 commit in takanabe/github-actions-automate-projects/tree/accept-other-event takanabe/github-actions-automate-projects/tree/master

0 comment

2 changed files

pr created time in 2 months

create barnchtakanabe/github-actions-automate-projects

branch : accept-other-event

created branch time in 2 months

issue commenttakanabe/github-actions-automate-projects

Workflow fails to add a pr to a project

I think this error might be caused by that the pr is opened from a forked repo.

ah, yes! this must be the root cause of 401 error.

BobAnkh

comment created time in 2 months

issue commenttakanabe/github-actions-automate-projects

Workflow fails to add a pr to a project

@BobAnkh

Hi!

GitHub Projects belong to organizations, repositories, and users. This GitHub action currently does not support user-based GitHub Project.

This action does not support user-based GitHub Projects because [go-github])https://github.com/google/go-github/pull/1295 didn't support when I wrote this actions. I may support user-based project as well in my spare time.

BobAnkh

comment created time in 2 months

startedpercona/go-mysql

started time in 2 months

startedjingweno/upterm

started time in 2 months

delete branch cookpad/terraform-aws-eks

delete branch : tw/specify-value-for-ignore-daemon-sets

delete time in 2 months

push eventcookpad/terraform-aws-eks

Takayuki WATANABE

commit sha cb8fb16dcaeb0063df854d6d76eab7db60f04e5f

Specify true for IGNORE_DAEMON_SETS in aws-node-termination-handler manifest aws-node-termination-handler behaves as bellows when it gets spot interruption and EC2 maintenance events. * if `--ignore-daemon-sets` is specified and the value is `true`, aws-node-termination-handler ignores DaemonSet and drains other pods (`kubectl drain --ignore-daemon-sets`) * if `--ignore-daemon-sets` is specified and the value is `false`, aws-node-termination-handler drains all pods. If there are DaemonSets, the drain for all pods does not happen (`kubectl drain`) * if `--ignore-daemon-sets` is not specified and `IGNORE_DAEMON_SETS` is not passed, aws-node-termination-handler ignores DaemonSet and drains other pods (`kubectl drain --ignore-daemon-sets`) * if `--ignore-daemon-sets` is not specified and `IGNORE_DAEMON_SETS=true` is passed, aws-node-termination-handler ignores DaemonSet and drains other pods (`kubectl drain --ignore-daemon-sets`) * if `--ignore-daemon-sets` is not specified and `IGNORE_DAEMON_SETS=false` is passed, aws-node-termination-handler drains all pods. If there are DaemonSets, the drain for all pods does not happen (`kubectl drain`) * if `--ignore-daemon-sets` is not specified and `IGNORE_DAEMON_SETS=ANY_VALUE_EXCEPT_FRO_TRUE_AND_FALSE` is passed, aws-node-termination-handler drains all pods. If there are DaemonSets, the drain for all pods does not happen (`kubectl drain`) Currently IGNORE_DAEMON_SETS is empty and `--ignore-daemon-sets` is not specified. Thus, aws-node-termination-handler tries to ignore DaemonSet. This is difficult to understand and IGNORE_DAEMON_SETS should have an explicit value. Code: https://github.com/takanabe/aws-node-termination-handler/blob/master/pkg/config/config.go#L108-L108

view details

Takayuki Watanabe

commit sha 32b565ceebf7784e3206fe7cd63b2cd42a83a357

Merge pull request #126 from cookpad/tw/specify-value-for-ignore-daemon-sets Specify true for IGNORE_DAEMON_SETS in aws-node-termination-handler manifest

view details

push time in 2 months

PR merged cookpad/terraform-aws-eks

Specify true for IGNORE_DAEMON_SETS in aws-node-termination-handler manifest

Change

Specify IGNORE_DAEMON_SETS=true for aws-node-termination-handler

Background

aws-node-termination-handler behaves as follows when it gets spot interruption and EC2 maintenance events.

if --ignore-daemon-sets is specified and the value is true, aws-node-termination-handler ignores DaemonSet and drains other pods (kubectl drain --ignore-daemon-sets)
if --ignore-daemon-sets is specified and the value is false, aws-node-termination-handler drains all pods. If there are DaemonSets, the drain for all pods does not happen (kubectl drain)
if --ignore-daemon-sets is not specified and IGNORE_DAEMON_SETS is not passed, aws-node-termination-handler ignores DaemonSet and drains other pods (kubectl drain --ignore-daemon-sets)
if --ignore-daemon-sets is not specified and IGNORE_DAEMON_SETS=true is passed, aws-node-termination-handler ignores DaemonSet and drains other pods (kubectl drain --ignore-daemon-sets)
if --ignore-daemon-sets is not specified and IGNORE_DAEMON_SETS=false is passed, aws-node-termination-handler drains all pods. If there are DaemonSets, the drain for all pods does not happen (kubectl drain)
if --ignore-daemon-sets is not specified and IGNORE_DAEMON_SETS=ANY_VALUE_EXCEPT_FRO_TRUE_AND_FALSE is passed, aws-node-termination-handler drains all pods. If there are DaemonSets, the drain for all pods does not happen (kubectl drain)

Currently IGNORE_DAEMON_SETS is empty and --ignore-daemon-sets is not specified. Thus, aws-node-termination-handler tries to ignore DaemonSet. This is difficult to understand and IGNORE_DAEMON_SETS should have an explicit value.

Related information

Code: https://github.com/takanabe/aws-node-termination-handler/blob/master/pkg/config/config.go#L108-L108

+1 -1

1 commit in cookpad/terraform-aws-eks/tree/tw/specify-value-for-ignore-daemon-sets cookpad/terraform-aws-eks/tree/master

0 comment

1 changed file

takanabe

pr closed time in 2 months

PR opened cookpad/terraform-aws-eks

Specify true for IGNORE_DAEMON_SETS in aws-node-termination-handler manifest

Change

Specify IGNORE_DAEMON_SETS=true for aws-node-termination-handler

Background

aws-node-termination-handler behaves as bellows when it gets spot interruption and EC2 maintenance events.

if --ignore-daemon-sets is specified and the value is true, aws-node-termination-handler ignores DaemonSet and drains other pods (kubectl drain --ignore-daemon-sets)
if --ignore-daemon-sets is specified and the value is false, aws-node-termination-handler drains all pods. If there are DaemonSets, the drain for all pods does not happen (kubectl drain)
if --ignore-daemon-sets is not specified and IGNORE_DAEMON_SETS is not passed, aws-node-termination-handler ignores DaemonSet and drains other pods (kubectl drain --ignore-daemon-sets)
if --ignore-daemon-sets is not specified and IGNORE_DAEMON_SETS=true is passed, aws-node-termination-handler ignores DaemonSet and drains other pods (kubectl drain --ignore-daemon-sets)
if --ignore-daemon-sets is not specified and IGNORE_DAEMON_SETS=false is passed, aws-node-termination-handler drains all pods. If there are DaemonSets, the drain for all pods does not happen (kubectl drain)
if --ignore-daemon-sets is not specified and IGNORE_DAEMON_SETS=ANY_VALUE_EXCEPT_FRO_TRUE_AND_FALSE is passed, aws-node-termination-handler drains all pods. If there are DaemonSets, the drain for all pods does not happen (kubectl drain)

Related information

Code: https://github.com/takanabe/aws-node-termination-handler/blob/master/pkg/config/config.go#L108-L108

+1 -1

1 commit in cookpad/terraform-aws-eks/tree/tw/specify-value-for-ignore-daemon-sets cookpad/terraform-aws-eks/tree/master

0 comment

1 changed file

pr created time in 2 months

startedboz/kail

started time in 2 months

delete branch takanabe/aws-node-termination-handler

delete branch : tw/fix-explanation-of-ignore-daemon-sets-flag

delete time in 2 months

PR opened aws/aws-node-termination-handler

Fix explanation of ignore-daemon-sets flag

The ignore-daemon-sets flag is compatible with kubectl drain --ignore-daemonsets. It literally ignores daemon sets to proceed a drain. However, the description of ignore-daemon-sets flag says