stackabletech / stackabletech/commons-operator
Pod expiration drifts when system is suspended
Dieses Issue hat noch niemand übernommen.
- Vorherrschende Sprache
- Python
- Sterne
- 8
- Forks
- 4
- Ø Merge
- 7 Std. 48 Min.
- Gemergte PRs (30 T.)
- 7
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
Beitragsleitfaden
Für dieses Repository ist kein Beitragsleitfaden indexiert
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
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.
Bewertung
- Tech-Stack
- kubernetes, rust
- Bereich
- devops, infrastructure
- Issue-Typ
- Bug
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Aktivitätsstatus
- Veraltet
- Klarheit
- Muss geklärt werden
- Anfängerfreundlichkeit
- 35/100