I’ve been planning an expedition to Broad Peak and K2 for almost two years now. At first the plan was to climb last summer, but then covid ruined that. The expedition was then rescheduled to this summer, while last summer I visited Denali instead. However my departure to Pakistan faced some unexpected obstacles.
大型遠征が近づくと、体力を整えるためにトレーニングで行く登山の時間も伸びるが、毎週毎週同じ道歩くのも飽きる。御岳から名栗湖に抜けるルートは楽しいが、代替もほしいので今度は奥多摩から鋸山、大岳山、御岳山と日の出山を超えるルートを試してみた。最初行ったときは逆方向で御岳から登ったが、日の出山から下るようにすることで終わったらつるつる温泉に入れるのでありがたい。
ここ何年もずっと同じところに住んでるけど、ここ最近でした発見が２件もあって、いつでも世界は新しい情報を渡してくれるなと思った。
まずは近くの高台から空気が澄んだ日の夕焼けの逆行で富士山（の輪郭）が見える。山頂の方しか見えないから、想像するような富士山じゃなく「えっそんなに山頂平だっけ？」と思いそうになるような富士山（案外平です）。その形状だから最初に見たときに目を疑ったけど方向と剣ヶ峰の尖りで間違いない。
そして背景（西方面）が曇っていると逆に田無タワーがはっきり見えることも最近の発見。前職でよく青梅街道の西遊記運転していつも前方の田無タワーが印象的だったが、住宅街からは普段見えない。ただしある（朝のジョギングで毎日のように通る）橋から見るとちょうど見える。最初気づいたのは（同じ方向に高圧電線も見えるから）形じゃなくその頂点の白いライトで、そこからよく見ると実は田無タワーの特徴的なあの形がお見え。
こうしてウン年住んでもまだ新しい発見があるから、新しいこと探す目を失わないようにね…
御嶽駅から惣岳山超えて岩茸石山を往復するのは定番のトレーニングルート。往復で3時間ちょいで始発で行くなら午前中に家に帰れる半日の計画。一方で電車の方も同じぐらいの時間がかかってちょっともったいないの気持ちにもなる。それと、大型遠征が近づくとトレーニングで動きたい時間も長くなるから3時間じゃ足りない。新穂高から西穂か槍行く手はあるが、金銭的に東京周辺がありがたい。時間的に雲取山も選択肢に入るが、そこはあまりにもルートがおもしろくなくて毎週のようには行きたくない。岩茸石山のルートでずっと気になってた「関東ふれあいの道」を調べたらひらめいた。
I was thinking about how nice it would be if I could see on my main Grafana dashboard (the only one I use at this point actually) when there are new versions of something deployed. This way if by chance there is a problem with something afterwards I can see at a glance what could have gone wrong. Also I really like just looking at that Grafana dashboard and see that everything is alive and well. (Except when it isn’t.)
You’d expect that with Japanese people being among the top mountaineers on 8000 peaks, the country having a healthy scene for winter sports it shouldn’t be hard to get advanced mountain gear, right? Let’s share some stories.
I’ve already written about what was going on most of last year in my birthday post, but so many people around me are writing year-end/year-start summaries that nudged me to revisit the topic as well.
The other day I was struggling with a very weird error when upgrading to Ruby 3. The initial migrations for a Rails app would fail with “Mysql2::Error: Unknown MySQL error (ActiveRecord::StatementInvalid)”, but only in certain environments. The error would occur when Rails tried to check what migrations are already applied by looking at the schema_migrations table.
2022-01-19 09:12:59.205 +0000 [DEBUG] (1.7ms) SELECT GET_LOCK('4252831219231700070', 0)
/usr/local/bundle/gems/mysql2-0.5.3/lib/mysql2/client.rb:131: warning: rb_tainted_str_new_cstr is deprecated and will be removed in Ruby 3.2
2022-01-19 09:12:59.222 +0000 [DEBUG] (2.0ms) SELECT `schema_migrations`.`version` FROM `schema_migrations` ORDER BY `schema_migrations`.`version` ASC
2022-01-19 09:12:59.224 +0000 [DEBUG] (1.8ms) SELECT RELEASE_LOCK('4252831219231700070')
rails aborted!
ActiveRecord::StatementInvalid: Mysql2::Error: Unknown MySQL error
/usr/local/bundle/gems/mysql2-0.5.3/lib/mysql2/client.rb:131:in `_query'
日本に戻った。簡単じゃなかった。
向こう滞在中に国がオミクロン危険地区みたいな指定食らってしまって、日本に戻るとPCR検査いくらあってもワクチンいくら打ってても問答無用で指定施設に数日いないといけない。意味不明。
到着は成田だったのでその付近のホテルが宿泊施設として指定された。ホテルの館一つまるごとがその目的に割り当てられてるっぽくて貸し切り状態。とはいえ受付済んで部屋に入ったら部屋から出られなくなるから、一階にコンビニがあってもモンエナ買いにいけずつらかった。
Symptoms: CPU load on all the nodes, but not the pods. Looking at Grafana, I noticed that CPU load on some of my nodes was constantly very high. At the same time, even the total CPU use of all the pods summed wasn’t above 0.4. What gives? This usually gives that the control plane is getting fried by something. It may be trying to relieve disk pressure, or in this case, trying to revive CSI.
Trying to figure out what was causing problems I checked the pods in kube-system with kubectl get pods -n kube-system. It quickly became apparent that there is a problem: disk-related pods like csi-resizer, csi-snapsotter and csi-provisioner were in CrashLoopBackOff.
I’ll be quite honest in that I’m not sure what the problem was. A few searches later I came to the conclusion that an earlier node reboot had left the pods with a corrupted DNS cache or something along those lines. Basically every issue I found with the symptoms I was seeing came down to DNS problems (longhorn/longhorn#2225, longhorn/longhorn#3109, rancher/k3os#811).
Alas I haven’t touched any of the networking machinery of Kubernetes (nor configured any of it for k3s) so my first idea was just the good old one from IT Crowd: “have you tried turning it off and on again?” So I did. Luckily another restart of the afflicted nodes solved the issue. I’m glad it did because I dread what I’d have had to do otherwise.