DaemonSet readiness accepts status from an older generation
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 84/100
Línea de trabajo
Comienza en internal/state/state_skel.go, en isDaemonSetReady, y luego sigue cómo llega su resultado a getSyncState. Reproduce el caso de DaemonSet tipado con el patrón de fake-client de Kubernetes del repositorio e inspecciona la regresión mencionada en torno a la transición de notReady a ready. Se considera terminado cuando la readiness espera a la generación observada actual, preservando el comportamiento con cero nodos y las comprobaciones existentes del recuento de pods.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
On current main 60526e35, internal/state/state_skel.go:isDaemonSetReady checks ObservedGeneration only when the desired pod count is zero. For a nonempty DaemonSet, equal desired/available/updated counts are accepted even when the controller has only observed the previous generation.
A DaemonSet with metadata.generation=3, status.observedGeneration=2, and desiredNumberScheduled=numberAvailable=updatedNumberScheduled=2 is currently reported ready. Those counts describe the previous template. This result also reaches the state aggregation through getSyncState.
Expected: wait until the DaemonSet controller observes the current generation, then apply the existing pod-count checks. The zero-node steady state should retain its current behavior.
Kubernetes defines observedGeneration as the most recent generation observed by the DaemonSet controller: https://kubernetes.io/docs/reference/kubernetes-api/apps/daemon-set-v1/
Reproduced with typed DaemonSet objects and through the actual state aggregator using the repository's Kubernetes fake-client pattern. A regression checks the notReady-to-ready transition after a status update. No live cluster is involved. This is separate from the pending DaemonSet update-strategy and Service reconciliation changes.
- Lenguaje dominante
- Go
- Estrellas
- 2.9k
- Forks
- 552
- Merge medio
- 2 d 3 h
- PR fusionados (30 d)
- 74
Preparar el entorno
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de NVIDIA/gpu-operator
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
NVIDIA/gpu-operator#2955 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
lifecycle/stale question
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
NVIDIA/gpu-operator#2280 · 2 comentarios · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 68/100
NVIDIA/gpu-operator#2957 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
feature lifecycle/frozen needs-triage
Dificultad 3/5 1-2 días Aptitud para principiantes 65/100
NVIDIA/gpu-operator#2938 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
NVIDIA/gpu-operator#2923 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de NVIDIA/gpu-operator
Issues similares
-
agent-butler-finding chore
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
jordansmall/spindrift#4146 ·
Los mantenedores suelen responder en 1 día
-
security
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
IBM/ibmcloud-volume-file-vpc#119 ·
-
security
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
IBM/networking-go-sdk#339 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
kubernetes-sigs/mcp-lifecycle-operator#439 ·
Los mantenedores suelen responder en 1 día
-
area: global bug dx priority: low
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día