Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#2,490 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
1-2 giorni
Idoneità per principianti
15/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go, kubernetes
Ambito
infrastructure

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
Go
Stelle
93
Fork
93
Merge medio
1g 12h
PR unite (30g)
26

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di openshift/oadp-operator

Tutte le issue di openshift/oadp-operator

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.