Pod expiration drifts when system is suspended
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 35/100
- Issue-Typ
- Bug
- Klarheit
- Muss geklärt werden
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- kubernetes, rust
- Bereich
- devops, infrastructure
Rechercherichtung
Beginne damit, den commons-op-Re-Reconciliation-Timer zu lokalisieren und zu prüfen, wie sich kube-rs-Timer bei System-Suspend und -Resume verhalten. Reproduziere wenn möglich die verzögerte Pod-Eviction und ermittle anschließend, ob ein Upstream-Fix in kube-rs oder eine Änderung in commons-op angemessen ist. Als erledigt gilt die Aufgabe, wenn abgelaufene Zertifikate nach dem Resume zeitnah zur Eviction führen und dies durch eine Regressionstestabdeckung oder ein Upstream-Issue dokumentiert ist, das die Einschränkung festhält.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Affected Stackable version
dev (24.11 prerelease)
Current and expected behavior
@xeniape ran into an issue (sble employees: see slack) where pods would be left with expired certificates after a while, rather than getting evicted by commons-op as expected. Restarting commons-op evicted the pods, as expected.
Our current working hypothesis here is that commons-op's re-reconciliation timer didn't advance while the computer was suspended, causing the eviction to be delayed by the same amount of time.
Possible solution
Either:
- Change the timer to use wall time instead of monotonic/CPU time
- Cap the re-reconciliation timer, causing spurious reconciles but at least limiting the issue
- Make the timer automatically expire when resuming from suspend
Either way, we should probably also communicate upstream with kube-rs and either fix it there or highlight the issue somehow.
Additional context
No response
Environment
No response
Would you like to work on fixing this bug?
None
- Vorherrschende Sprache
- Python
- Sterne
- 8
- Forks
- 4
- Ø Merge
- 1 T. 7 Std.
- Gemergte PRs (30 T.)
- 8
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Kein Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus stackabletech/commons-operator
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 25/100
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 38/100
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 25/100
-
Dependency DashboardOffen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 15/100
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 35/100
stackabletech/commons-operator#235 · 1 Kommentar ·
Alle Issues in stackabletech/commons-operator
Ähnliche Issues
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
lugassawan/swe-workbench#799 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
vllm-project/vllm#61131 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Non-string form field names raise AttributeError when files are attachedEvtl. vergeben @nightcityblade hat das heute übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
kubernetes-client/python#2735 ·
Maintainer antworten meist innerhalb von 1 Tag
-
desktop help wanted test
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag