TT Lab
ブログ

한국어 English 日本語 中文

はじめる
ブログ

ブログ

2年前に非推奨になった spec.running をドキュメントがまだ1行目に書いているとき：KubeVirt ユーザーガイドのPRが10日足らずでマージされるまで

2026-10-28 · 14 分で読めます · #오픈소스#오픈소스 기여#KubeVirt#쿠버네티스#문서#오픈소스 기여 기록

結果：マージ（2026-10-27 00:04、 kubevirt/user-guide#1040). 実はGitHubのPR・レビュー・コメント・タイムライン・チェック履歴、関連issue・PR、ユーザーガイドのソース（PRのベースコミット 0ca33477）、KubeVirtのソース（タグ v1.9.0）、 コントリビューション台帳のドラフト、TT LabリポジトリのVM作成コードから取得しました。時刻は韓国時間です。

目次

一言まとめ
PR kubevirt/user-guide#1040 docs: mark spec.running as deprecated in favor of runStrategy
変更点 run_strategies.md（紹介文をrunStrategy優先に、非推奨の警告ボックス、タイポ1つ）、 architecture.md（周辺の文章3つ、 virtctl コマンド1つ）。27行追加、15行削除
反応 approverが1時間37分後に /approve. /lgtm は9日後に別のメンテナーが歓迎の挨拶とともに
結果 PR公開 10-17 00:51 → /approve 02:28 → /lgtm 10-27 00:04 → マージ30秒後、約9日23時間13分

1. 何が問題だったのか：警告は出るのにドキュメントは静か

KubeVirt の VirtualMachine は、VMを起動するかどうかをかつては真偽値フィールド spec.running で、現在は spec.runStrategy(Always·Halted·Manual· RerunOnFailure など）で決定します。 spec.running は kubevirt/kubevirt#12578（2024-09-30マージ）で 非推奨としてマークされ、ユーザーガイドの v1.4.0 リリースノートの「Deprecation」にも掲載されました。

APIはこのことを明確に示しています。PRの本文に記載した、v1.9.0クラスターで確認した内容です。

kubectl explain の出力はPRの本文にのみ記載し、台帳に出力のオリジナルファイルは残していません。

しかし、ユーザーガイドのRun Strategiesページの最初の文は「VirtualMachine には guest を動かすかどうかを決める Running 設定がある」であり、非推奨については1度も 触れていませんでした。runStrategy を探してそのページにたどり着いた人も、最初の段落で running: true を学んで帰ることになります。

TT Labにも同じ状況があります。受講生用VMを作成するコード（TT Labリポジトリ backend/app/vms.py）は今でもマニフェストに "running": True を含め、 実行されているかどうかもそのフィールドで読み取っています。すぐ上のコメントには「running は deprecated だ、runStrategy に移行する方が正しいが、現在動いているVMと動作を合わせるためにそのままにしておく」 と書かれています。コントリビューション台帳にも「TT Labが非推奨のフィールドで学生用VMを作成・読み取りしている、このPRと同じテーマ」と記されており、移行作業は別途切り出しています。 2026-10-29時点でもまだ移行できていません。他人のドキュメントを直している間、私たちのコードも同じ借金を抱えていることを正直に書き留めておきます。

2. 原因：ドキュメントのどの行か

行番号はPRのベースコミット 0ca33477 を基準としています。

Run Strategiesページ

アーキテクチャページ

この非推奨を修正しようとした試みは過去にもありました。issue #923（2025-09-15）ではVMのライフサイクルとRunStrategyのドキュメントを 修正しようとし、PR #927（2025-09-17）では非推奨の表記を関係のないtolerationsの変更と一緒に盛り込んでいました。 どちらもレビューなしでBotにより非アクティブとしてクローズされました（2026-02-14、2026-03-22）。

3. 何を変えたのか：diffの要点

 # docs/compute/run_strategies.md, Overview
-VirtualMachines have a `Running` setting that determines whether or not
-there should be a guest running or not. ...
+VirtualMachines have a `spec.runStrategy` field that determines whether
+or not there should be a guest running, and what KubeVirt should do when
+the guest stops.
+
+Older manifests use the boolean `spec.running` field instead. ... (기존 설명은 이 문단으로 옮김)
+
+!!! warning
+    `spec.running` is deprecated since KubeVirt v1.4.0. Use
+    `spec.runStrategy` instead: `spec.running: true` corresponds to
+    `runStrategy: Always`, and `spec.running: false` corresponds to
+    `runStrategy: Halted`. The API server still accepts `spec.running`,
+    but returns the warning ... when a VirtualMachine that sets it is created or updated.
-    associated ith the VM.
+    associated with the VM.

 # docs/architecture/architecture.md
-If a VirtualMachineInstance reaches a final state but the `spec.running`
-equals `true`, ...
+If a VirtualMachineInstance reaches a final state but the
+`spec.runStrategy` equals `Always`, ...
-Since `spec.running` is set to `false`, no vmi will be created:
+Since `spec.runStrategy` is set to `Halted`, no vmi will be created:
-$ virtctl start vm vm-cirros
+$ virtctl start vm-cirros
-  Running:  true
+  Run Strategy:  Always

説明を削除したわけではありません。「真偽値1つではguest内でシャットダウンする場合を表現できない」という従来の説明は、runStrategyがなぜ生まれたのかを教えてくれる良い段落なので、 「古いマニフェストは spec.running を使用する」の後ろに移動しました。そして、新しく使い始める人が最初に目にする文をrunStrategyに変更し、古いフィールドから新しいフィールドへの 対応表（true → Always, false → Halted）とAPIサーバーが出力する警告文を警告ボックスに入れました。警告文をそのまま記載したのは、検索によってこのページにたどり着くように するためです。

PRの本文の最後には #923・#927 が同じテーマを扱っていたがレビュー前にクローズされたこと、このPRは非推奨のみを扱うことを記載しました。AIの使用はコミットのフッター Co-Authored-By: Claude Opus 5.5 と Signed-off-by、および本文の終わりの「AIの助けを借りてドラフトを作成し、自分がレビューした」という1文で明かしました。 KubeVirt の AIコントリビューションポリシーに則った形です。コミットにはSSH署名が付いています。 ドキュメントのビルド（mkdocs）はローカルでは実行せず、マージ前にNetlifyのプレビューが作成されました。

4. 反応：approveは1時間37分、lgtmは9日

時刻 日
10-17 00:51 PR公開。prow が needs-ok-to-test·size/M ラベル、レビュアー2人を指定
10-17 02:28 approver が /approve. approved ラベル
10-26 17:29 9日間 /lgtm がなかったため、別のメンテナーを /cc し、「approveがあり、lgtmだけが残っている」とお願い
10-27 00:04 そのメンテナーが /lgtm、「修正してくれてありがとう、プロジェクトへようこそ」
10-27 00:04 30秒後にtideがマージ

このリポジトリにはPRごとに実行されるテストジョブがないため、 needs-ok-to-test ラベルが最後まで付いていましたが、マージには影響ありませんでした（台帳の記録）。残りのチェックはDCO、 Netlifyプレビュー、tideの3つでした。必要だったのは人の /approve と /lgtm の2つだけであり、1つ目はすぐに来ました。

2つ目が来なかった9日間の間、私たちは台帳に「10/26頃に音沙汰がなければ /cc しよう」と日付を書き留めて待っていました。その日に一度お願いし、6時間35分後に /lgtm が来ました。

後から見ると、 /lgtm をくれたメンテナーは1年前にissue #923 を開いた人物でした。同じ問題を認識しており、誰かが修正してくれるのを待っていた人にPRが届いた ものとみられます。PRの本文に #923 を記載しておいたことも、その結びつきを容易にしたと考えられます。

5. 学んだこと：オープンソースコントリビューションのコツ

ティティの一言。 遊び場の案内板の1行目に「ブランコは赤いボタンでつけてね」と書いてありました。でも赤いボタンを押すと「このボタンはもうすぐなくなります、青い手すりを 使ってください」という声がします。もう2年目です！案内板の1行目を青い手すりに変えて、赤いボタンの話は「かつては」の欄に移動しました。9晩待っていたら、1年前に 「案内板を直してください」とメモを書いてくれた先生が来て「よく来たね！」とスタンプを押してくれました。でも私たちの遊び場のブランコも、まだ赤いボタンをつけて動かしています。これはすぐ直しますね。

リンク

すべての資料は2026-10-29に閲覧しました。

ログインするといいねできます

コメント

まだコメントはありません。

ログインするとコメントできます