stackabletech / stackabletech/commons-operator
Pod expiration drifts when system is suspended
Personne n'a encore pris cette issue.
- Langage dominant
- Python
- Étoiles
- 8
- Forks
- 4
- Merge moyen
- 7 h 48 min
- PR mergées (30 j)
- 7
Description
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
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par localiser le timer de re-réconciliation de commons-op et examiner le comportement des timers de kube-rs lors de la mise en veille et de la reprise du système. Reproduisez si possible l’éviction retardée du pod, puis déterminez s’il convient d’apporter un correctif upstream à kube-rs ou une modification à commons-op. La tâche est considérée comme terminée lorsque les certificats expirés entraînent une éviction rapide après la reprise, avec une couverture de régression ou une issue upstream documentant la limitation.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- kubernetes, rust
- Domaine
- devops, infrastructure
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- À l'abandon
- Clarté
- À clarifier
- Accessibilité débutants
- 35/100