Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#2,490 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
1-2 días
Aptitud para principiantes
15/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go, kubernetes
Área
infrastructure

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Go
Estrellas
93
Forks
93
Merge medio
1 d 12 h
PR fusionados (30 d)
26

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de openshift/oadp-operator

Todos los issues de openshift/oadp-operator

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.