ステータス: ドラフト（2026-10-17）、リポジトリのドキュメント＋ファイルの実測。 基準は KubeVirt v1.9.0（コミット 79d34c17）の CONTRIBUTING.md, docs/reviewer-guide.md, docs/getting-started.md、OWNERSファイル、PRテンプレートです。テストとビルドは実行していません。

KubeVirt ソースコードリーディング 8: コントリビューション入門

目次

• 1. 直観：人間の判断とボットのラベル
• 2. 図
• 3. OWNERSで地図を再び見る
• 4. コマンドとラベル
• 5. レビューガイドが注目するポイント
• 6. 最初のコントリビューションに適した場所
• 7. テストの実行方法と必要なツール
• 8. 制限事項
• 参考

1. 直観：人間の判断とボットのラベル

KubeVirtのPRは、2人の人間の判断があって初めてマージされます。 reviewer が「コードが良い」と話し、/lgtm), approver が「このリポジトリに入れてよい」/approveと言います。誰がreviewer・approverであるかは、PRが触れたフォルダの OWNERS ファイルが定め、その意志表示はPRコメントのスラッシュコマンドで行います。その言葉をラベルに変換し、テストレーンを実行し、条件がすべて揃ったらマージするのは、 prow というボットのセットです。Kubernetesと同じ方式であるため、一方を学べばもう一方でも活用できます。

2. 図

3. OWNERSで地図を再び見る

v1.9.0にはOWNERSファイルが 141個 存在します（実測）。ルートの OWNERS はすべてのファイルのデフォルトのreviewer・approverをエイリアス code-reviewers·approvers として定め、ビルドファイル（BUILD.bazel, Makefile など）は sig-buildsystem で個別に処理します。フォルダ内のOWNERSはさらに限定されます。例えば第3篇の pkg/virt-controller/watch/vm/OWNERS は次のようになります。

reviewers:
  - sig-compute-reviewers
approvers:
  - sig-compute-approvers
labels:
  - area/controller
  - sig/compute

出典：kubevirt/kubevirt v1.9.0 pkg/virt-controller/watch/vm/OWNERS（コメント行を除く、Apache-2.0）。このフォルダを変更したPRにはprowが sig/compute·area/controller ラベルを付与し、sig-computeからレビュアーを選出します。エイリアスの実際の名簿は OWNERS_ALIASES にあります。 人数を集計すると次のようになります（v1.9.0、実測）。

この表こそがまさに コードの地図のもう一つの顔です。第4・5篇のネットワークコード（pkg/network, converter/network）はsig-network、第6篇のストレージ側 （pkg/storage）はsig-storage、残りの大部分はsig-computeが担当します。レビューを早く受けたい場合は、PRを1つのSIGのフォルダ内に収めるのが得策です。複数のSIGにまたがると、複数のapproverが必要になります。

4. コマンドとラベル

マージは人がボタンを押すのではなく、 tide が行います。2つのラベルとテストの通過が満たされ、ブロック用のラベル（do-not-merge/…, /hold）がなければキューに追加されます。ドラフト（draft）PRはCIが実行されず、レビュアーもアサインされないため、方向性を相談したい場合はドラフトとしてオープンするのがマナーです。

PRに必ず含めるべきものは3つあります。

1. すべてのコミットの Signed-off-by: — DCO。 git commit -s で付与します。ないとDCOチェックにブロックされます。
2. PRテンプレートの release-note ブロック — ユーザーに表示される変更であれば1行、そうでなければ NONE。リリースノートはこのブロックから生成されます。
3. テスト — レビューガイドの最低ラインは「新しいコードには単体テスト、新機能とバグ修正には1つ以上のe2eテスト」です （reviewer-guide.md:103 周辺）。

コミットメッセージはKubernetesのルールに従います（docs/commit-message-guidelines.md）。タイトルは50文字前後・命令形・ピリオドなし、本文は72文字で改行し、本文には何と なぜを記載し、 Fixes #123 のようなキーワードはコミットではなくPRの説明に記述します。冒頭に net, vmi: のような領域のプレフィックスを付ける例がドキュメントに記載されています。また、v1.9.0のPRテンプレートのチェックリストには、 KubeVirt AIコントリビューションポリシーを遵守したかを確認する項目があります。ツールの助けを借りて作成したPRである場合は、そのポリシーを事前に読んでください。

5. レビューガイドが注目するポイント

docs/reviewer-guide.md は短いですが、前述の7篇で見てきた設計がなぜそのようになっているのかを逆から説明してくれます。レビューを受ける際に出される指摘を事前に予測することができます。

• ノードコンポーネントにインフォーマーを追加するな(:43（
• ）。第4篇でvirt-handlerがVMIをノードラベルでフィルタリングして監視する理由です。逆にvirt-apiでは、インフォーマーの代わりにGETを使用するよう求められます。virt-apiは自由スケールするコンポーネントであるため、キャッシュを持つとオブジェクト転送が急増するためです。 作成していないオブジェクトはPATCH、作成したオブジェクトはUPDATE。
• 第2篇のサブリソースがVMをJSONパッチで修正する理由です。statusを複数で共有して使用する場合は、フィールドを絞ったPATCHを使用するよう求められます（第3・4篇のVMI status）。 イベントは状態が変化した時のみ一度だけ。
• reconcileごとにイベントを発行するとAPIサーバーが過負荷になります。 リストの順序を維持せよ。
• 2つのコントローラーが同じ条件リストを異なる順序で操作すると「更新ストーム」が発生するという例が、まさにvirt-controllerとvirt-handlerのVMI条件です。 特権が必要なノード操作はvirt-launcherではなくvirt-handlerで。
• 第4・5篇の分業体制そのものです。 アップグレードパスを考慮せよ。
• 新しいvirt-handlerが古いvirt-launcherと通信できなければなりません（第4篇のproto）。 goimports·shfmtコーディングスタイルは nogo に従い、GoのよくあるミスはBazelの

アナライザーがビルド時に検出してくれます。

6.最初のコントリビューションに適した場所 本シリーズの地図から見ると、最初は1つのファイルとそのテストのみを変更する箇所

• がおすすめです。 good-first-issue·help-wanted·kind/bug ラベルで選ぶ。CONTRIBUTING.md ラベル（
• 49行目の案内）。 ドキュメントとコードの乖離。 docs/components.md 本シリーズを執筆中に1つ実際に確認しました。 libvirtd はポッド内のlibvirtデーモンを virtqemud と説明していますが、v1.9.0では
• を起動します（第1・5篇）。ドキュメントのPRはテストの負担が少なく、修正する過程でコードを正確に読み込むことができます。CDI側でサイズ計算をドキュメントに追加するPR（#4318）も同カテゴリです（第6篇）。 pkg/virt-launcher/virtwrap/converter/compute/ converterの設定を1つ追加・修正する。 _test.go のファイルはデバイスごとに分かれており、隣に
• があります（第5篇）。ダミーのクラスターなしでVMI → ドメイン構造体のみを確認する単体テストであるため、実行も容易です。 admitters/ ウェブフックのバリデーションとメッセージ。
• の関数は入力（スペック）と出力（StatusCauseのリスト）が明確です（第2篇）。エラーメッセージのフィールドパスや文言をブラッシュアップする作業も、レビューガイドが求める「合理的なエラーメッセージ」に合致します。 ログとイベント。 pos ログの

でコードを検索する方法（第1篇）を活用すると、同じ行が頻繁に出力されている箇所（第7篇のデバイス検証ログなど）を実際のクラスターで発見できます。修正する前にIssueで事前に質問することをおすすめします。

7. テストの実行方法と必要なツール

本記事の執筆にあたってはテストを実行しておらず、以下のツールもダウンロードしていません。必要な情報のみを記載します。 単体テスト。

make test                                    # Bazel 로 전체(빌더 컨테이너 안)
make go-test WHAT=./pkg/virt-controller/...  # Bazel 없이 go test (역시 컨테이너 안)

最も確実な方法は、リポジトリが指定するビルダーコンテナを使用することです。必要なのはDockerまたはPodman、rsync、そして初回のみ取得するビルダーイメージ（quay.io/kubevirt/builder:<판>, hack/dockerized 19行目）です。コンテナの外で go test を直接実行するには、 go.mod の go 1.26.0 に適合するGoと、virt-launcher側のパッケージがcgoで利用するlibvirt開発ヘッダー（libvirt.org/go/libvirt）が必要です。コンテナの外でどこまでのパッケージが動作するかはimportをたどって確認する必要があるため、今回は未確認です（未確認）。最初はコンテナを使用する方が手軽です。単体テストもGinkgoを使用しているため、個別で実行する際は -ginkgo.focus='문자열' を渡します。

機能テスト。 make cluster-up はkubevirtciでノードをVMとして起動したクラスターを作成し、 make cluster-sync が自身のビルドをデプロイし、 make functest が tests/ を実行します。一部のみを実行する場合は FUNC_TEST_ARGS='--focus-file=…' を使用します（docs/getting-started.md 221行目）。必要なのは、 ネストした仮想化（Nested Virtualization）が有効なLinuxマシーン（Macでは困難です）、十分なメモリ、そしてkubevirtciが取得するノードイメージです。PRではこのテストをprowのレーンがSIGごとに代行して実行してくれるため、最初は単体テストまでを自分のマシーンで実行し、機能テストはレーンの結果を確認することから始めても問題ありません。

8. 制限事項

• prowレーンの名前と数、tideの正確なマージ条件は kubevirt/project-infra リポジトリに存在し、今回は確認していません（未確認).
• エイリアスの人数はv1.9.0時点のファイルに基づいています。mainでは異なる場合があります。
• ビルド・テスト時間は 未実測です。

Tidから一言。 最初のPRは小さければ小さいほど良いです。1つのファイル、1つのテスト、そして変更理由を1段落！そしてレビューのコメントは攻撃ではなく、地図の空欄を埋めてくれるものです。感謝を伝えて1つずつ修正していけば大丈夫です！

参考

すべて2026-10-17に閲覧しました。

• CONTRIBUTING.md: https://github.com/kubevirt/kubevirt/blob/v1.9.0/CONTRIBUTING.md
• レビューガイド: https://github.com/kubevirt/kubevirt/blob/v1.9.0/docs/reviewer-guide.md
• コミットメッセージのルール: https://github.com/kubevirt/kubevirt/blob/v1.9.0/docs/commit-message-guidelines.md
• PRテンプレート: https://github.com/kubevirt/kubevirt/blob/v1.9.0/.github/PULL_REQUEST_TEMPLATE.md
• prowコマンド一覧: https://prow.ci.kubevirt.io/command-help
• KubeVirt AIコントリビューションポリシー: https://github.com/kubevirt/community/blob/main/ai-contribution-policy.md
• 開発ガイド（テスト）: https://github.com/kubevirt/kubevirt/blob/v1.9.0/docs/getting-started.md