再現できればこんなのはちょろいんだよ．再現できないのがきつい
まだ今の段階ではservice-account-issuerを設定してくれるだけなのか
あー全然ログが残ってなくて何が起こったのかが全然わからない，すべてが妄想の域でしかない
なんでis_requiredみたいな，明らかにフラグっぽいものがintで定義されてるんだよ．何が入るんだよ
まったくマジックナンバーばっかりで読みにくくてしょうがない，相変わらずのクソコードだ．なんでvalue objectとかちゃんと作れないのか
あれ，transportが指定されたときはそれを使ってるけど，指定されてないときはキャッシュからとってないか？
client-goのNewForConfigするとhttp.DefaultTransportの設定値が有効になっていない気がする
いい加減直し方はわかってきた．あとは原因だ．これなんでdefaultTransportを使うとtcpを貼り直さないんだろ
http2を切ったとしても同じエラーが観測できる．つまりこれ自体はhttp2のhealth checkが問題ではない．http2を入れようが入れまいが，tcpのconnectionの貼り直しが発生していないのはなぜなんだ
これかと思ったんだけど，原因はこれだけじゃないな．http2を使わなくてもconnectionは再利用されている．ログを見ればわかるけど，transportをnewするのは最初の1回だけで残りはキャッシュを使ってるのか
https://github.com/kubernetes/kubernetes/pull/95981
kops 1.21からIRSAのセットアップが自動化されるの，まじで最高なんやが
だいぶいいとこまできたな．LBまでは疎通してる．問題はLBがkeep-aliveに反応しているが，その裏側までリクエストが到達してない気がしてならない．少なくともkeep-aliveを短くすればそれで対応は可能だなぁ
あーexecでpod内部でtcpdumpしながら出力を手元のwiresharkに食わせられるかな
何も設定していないときにkeepaliveしてるなんてことないよな？idle connectionが普段どのくらい残ってるのか確認したいんだが
まじで全然わからん．これpod内に入っても正常に動いているし，エラーになったプロセス内でのみなにかがおかしい．何がおかしいんだよ
これもしかしてlbのタイプを変えたらいけるのではっていう気がしてきたぞい
俺の勘が正しければ，これはetcdは関係なくてmasterが死んだときに確率的に発生するのではないかと思ってるんだけど，違うんだろうか
hogehogeStatusでintとか定義するのやめてくれないかな……全然value objectの意味を理解してないじゃん
goのリリースバイナリをreleasesの添付ファイルにしているんだけど，これリリースタグ作ったらCIで自動ビルドして添付するようにできないかな
ActiveRecordはActiveRecord型ORMの中の最高傑作だよ
@marian @vic I created a pull request. How about this wording? Please review this.
https://github.com/h3poteto/whalebird-desktop/pull/2484
あとはCNIが壊れてる可能性は否定できないな．それであるならクラスタ内からだけエラーになる理由も多少は説明がつく
これ見た目的にはkube-apiserverまで疎通してない感じがするんだよなぁ．なんでなんだろ．ipは変わらないはずなのに．ちょっとdigし続けてみるかね……
これはclientsetの生成に問題があるか，secretとかキャッシュされてないか？controllerのpodを再起動したら治るんだが
このアカウントは、notestockで公開設定になっていません。
I released Whalebird version 4.4.1. I added filter settings. Filters will be synced with Mastodon/Pleroma server and it will be applied.
https://github.com/h3poteto/whalebird-desktop/releases/tag/4.4.1
#whalebird
Whalebird 4.4.1をリリースしました．フィルタの設定画面が追加されており，フィルタがサーバ側と同期されて適用されるようになります．
https://github.com/h3poteto/whalebird-desktop/releases/tag/4.4.1
#whalebird
あと真面目な話をすると，ホテルにしろ旅館にしろ仕事できるほどの椅子と机とインターネット回線が揃っているところが結構少ない
温泉はめっちゃいいんですけど，温泉入って観光してると仕事しないんですね
あーInstanceProfileを取得すれば紐付いてるRolesは取れる．つまりここのTagsをフィルタリングすればいける
InstanceProfileってそれ自体にはtagはつかないのか．紐付いてるIAM Roleのtagで判断するしかないのかなぁ
そしたら考えられるのは生成しているクライアントに問題があることくらいしかなくない？
あかん，何もわからなくなってしまった．迷子や
手元から叩くと成功するということが判明してしまった．余計わけわからんわ，なんでcontrollerから叩くとタイムアウトするねん
etcdを殺したときにmasterが複数台エラーになるんだけど，その状態から復旧できないパターンがあるなぁ
なぜetcdとmasterを同時に殺すとkube-apiserverが不通になるのか
この件，codecovから顧客情報まで抜かれたの，結構珍しいと思ったけど，ソースコード上に顧客情報乗っかってたのね
GitHubに上げてたソースコードに顧客情報が含まれてたんだ．それにしてもCodecovから漏れるのはすごいな / 他8件のコメント https://t.co/CStIReghs7 “「Codecov」への第三者からの不正アクセスによる当社への影響および一部顧客情報等の流出について | 株式会社メルカリ” https://t.co/q7ZvjrZrvD
kubeletのオプションから--network-pluginとか--cni-conf-dirが非推奨になるけど，これってもともとdocker-shimsでしか使ってなかったの？ということはcontainerdやCRI-Oを使っている場合にCNIのconfとかってどうやっていじればいいんだ？これってCRIの方になにか定義されているの？それにしても，その設定値をkubeletからいじれなくていいのか？
@sandycorzeta Thank you! I will add it.
テストデータをどうやって生み出すかは結構悩ましいな……．これによってcontextを分離したいねん
普通にec2しか許可されてないし，これでduration分だけエラー起こすくらいしかできなかった
あ，FISのapi-internal-errorって今の所ec2しかサポートしてないの
あーFISでもapi-internal-errorとかだとdurationを指定できるので，これは一定時間エラーを出し続けることができる．難しいなぁ
あーStop conditionはあくまで中止の条件であって，終了条件ではないのか．targetにしていたものがcompleteしたらstop conditionが上がってなくても終了しちゃう
FISって終了条件がむずいな．インスタンスを殺し続けてほしい場合は単にStartするだけじゃダメなのか．現存するインスタンスを殺し終わった時点でexperimentがcompleteになってしまう．Stop conditionにcloud watch指定したらもっと長期間殺し続けてくれるかな
それはそう思う．自社サービスのスタートアップの場合，品質を上げて利益を得るのは将来の自分たちだけど，受託開発で品質を上げ続けてもそれが利益になるのか？というのは怪しい．受託の方は全然温度感わからないので，そういうのを評価してくれるところもあるのかもしれないが
秤についてはt-wadaがいつもいいこと言ってるので，このへんに全部書いてあるとして．結局短期的な機能追加は得られても，長期的には品質を下げ続けるので，成長したときに苦労しろよって話でしかない
https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition
でもマジで書かない派の人は平時に何言ってもあんまり響いてないので半分諦めている．そういう意味でも "でもそれは、スタートアップだからでもスピード優先だからでもない。自分達が未熟だからで、そこには向き合うべきだと考えます。" というところは同意．書かないのではない，未熟だから書「け」ないのである
こういうのはいいんですよ，こういうのは．それは自分が楽な方を選んだら良い
わろたｗｗｗ確かにCTOがCIの変わりだわｗｗｗ性能がCIより遥かに低い（待ち時間が長い）けど
それはまぁ一人で開発してるならそうだし，別にいいんだけど，仕事で複数人でやるとなると状況はまったく逆転するよ．他人がかいたコードを確認する時間でテストコード一つ書けるよ．っていうのが人数分発生する
実際最近副業で入ったスタートアップが，全然テストがない（テストがないからCIという概念もない）んだけど，そのくせパフォーマンスが悪いからリファクタリングしてほしいと言う．リファクタリングするのにテストがないとはどういうことなのか．
PRを出すと毎回CTOが手動でpullして本番DB相当のデータを用意してポチポチいじって「ここでバグりました」みたいな報告を上げてくる．これを修正するたびにやるので，普通に1PRをマージするのに1ヶ月以上かかる．こんなのでいいのかスタートアップ？と思ってるんだけど，本人は危機感がまったくないらしく，テストを書く気もないらしい
一人ならともかく，複数人で開発するようになると，テストなしで他人のPRのレビューしてマージするのがかなり怖くなる．それをいちいち手元やdev環境用意して手動確認する暇がスタートアップにあるのか？ / “「スタートアップだからテストを書かない」は正しいか - An Epic…” https://t.co/HvZV75BAjA
fedibirdがemoji_reaction対応した結果，パースできないイベントがいっぱい飛んできている
星野源といえばSAKEROCKやってたイメージしかないのに，いつの間にか結婚してたし，いつの間にか解散してた
ほげ，どういうことじゃ．sshできない．インスタンス死んだんじゃね．なにもしてないのに
削除系のレビューは，削除範囲が正しいかの判定をするためにかなり広範囲のコード知識が要求されるんでむずかしいよね．とあるメソッドを削除しても問題ないかは，参照先をある程度把握してないと判断できない．
あーだめだ，deprecatedなフラグ使ってないと思って消したけど，やはりテストが通らない
あーちょっとわかった．これはちゃんと待たないとだめなんじゃないだろうか
kube-apiserverの--client-ca-fileと--etcd-cafileって別のCAであっても問題はないよな？つまりクライアント認証に使っているCAと，k8s内のコンポーネント同士が通信する際のCAって別物でいいはずだよな
すべてのCIが失敗している…これはもしや何かしらのlimitに到達したのでは
ようやく再現できたので対策はなんとかなるぞ．根本原因の修正は別だな……
あーこれは再現するぞ！再現するぞー！！！
ようやく正式なissueを作れる
お，少し進んだぞ．etcdより先にmasterを殺すとエラーになるのでは
botの自動コミットによって差分が消失した．ってことはこれわざわざ人がやる必要もないんじゃん……
あーわかっちゃーtruncateするときにschema_migrationsまでtruncateしてはいかん．これマジ大事
なんかこれMakefileが普通に使いにくいな……なんでこんなことしてるんだろうな……
Subway Tooterはいいぞ、いいぞ / 他37件のコメント https://t.co/961BZ9snMU “突然、紹介されるオススメAndroidアプリ集” (167 users) https://t.co/ByuLz4m8MV
database cleaner相当のことをだれがどうやってやるかが悩ましいな
etcdの台数増やしたら大丈夫な気がしなくもない．しかしそんなことをしたいんじゃないんだよ
やはりetcdを殺すと巻き込みで一部のkube-apiserverも死んで一時的にmasterが死ぬな．問題は復旧しないパターンを見つけられてないということか
distrolessでもdebugタグがついてるやつはshellが入っているのでデバッグに使うときには便利
distrolessは入ってる依存が最低限だし，goはバイナリ吐き出しちゃえばだいだいこれで動くので，最高だぞ
debianもslimはよく使う．一時期alpineが多かったけど最近alpine勢はみんなdistrolessに移行しつつあるイメージ
LLは別としてもgoは最近distrolessに詰め込んでしまうことが多い
CNIの載せ替えは，新しいクラスタ作って中身を移し替えるのは楽にいける．live migrationはちょっとたいへん．でもflannel -> calicoは割とやりやすいほうかも
ライブラリを更新するだけの仕事のはずなのに，依存関係解決できなくて全然ちょろくない
