Make kubevirt-datamover cluster-wide singleton check safe under concurrent DPA reconciles

オープン
  • 何か問題がありますか？
#2,490 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
1〜2日
初心者へのやさしさ
15/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go, kubernetes
領域
infrastructure

調査の方向性

Start in internal/controller/kubevirt_datamover_controller.go with checkKubevirtDatamoverClusterSingleton(), its call in ValidateDataProtectionCR, and ReconcileKubevirtDatamoverController around the CreateOrUpdate. Also check SetupWithManager for MaxConcurrentReconciles, which is currently left at the default of 1. The issue is conditional on future concurrency, so confirm with a maintainer before starting. Done means a lock held across the re-check and create, with the unlocked validator call kept.

索引モデルが issue の本文から書いたものです。

説明

Context

The kubevirt-datamover controller is a cluster-wide singleton: only one DPA across all namespaces may have the plugin enabled with a deployed controller. Enforcement lives in checkKubevirtDatamoverClusterSingleton() (internal/controller/kubevirt_datamover_controller.go), called from ValidateDataProtectionCR during the DPA reconcile batch.

The check-then-act sequence — validate early in the batch, create the Deployment much later in ReconcileKubevirtDatamoverController — has a TOCTOU window: two DPAs in different namespaces could both pass validation while neither deployment exists yet, and both end up deployed.

Why it is safe today

MaxConcurrentReconciles is never overridden in SetupWithManager, so it stays at controller-runtime's default of 1: Reconcile() calls for every DPA across every namespace are fully serialized, and the race cannot occur. This reliance is documented inline on SetupWithManager and on the check itself.

With multi-tenant DPA (one DPA per namespace, #2488) there is more reason than before to eventually raise reconcile concurrency for throughput.

What to do when concurrency is raised

Re-run checkKubevirtDatamoverClusterSingleton() under a mutex immediately before the CreateOrUpdate in ReconcileKubevirtDatamoverController (keep the unlocked call in the validator for fast feedback), and hold the lock across the create. This design was prototyped and live-tested during #2488 and then removed as defense-in-depth against a race that cannot occur under the current serialized configuration — see the PR's design doc for the full analysis, including why a lock spanning batch steps would be wrong (the batch aborts on intermediate errors and would hold the lock indefinitely).

Note a mutex only helps while leader election guarantees a single active controller replica, which is the case today.

Note: Posted using claude code
Model: GLM 5.3

主要言語
Go
スター
93
フォーク
93
平均マージ
1日 16時間
マージ済み PR（30日）
25

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

openshift/oadp-operator のほかの issue

openshift/oadp-operator の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。