Pod expiration drifts when system is suspended
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 35/100
- Type d'issue
- Bug
- Clarté
- À clarifier
- Activité
- À l'abandon
- Stack technique
- kubernetes, rust
- Domaine
- devops, infrastructure
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.
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
- Langage dominant
- Python
- Étoiles
- 8
- Forks
- 4
- Merge moyen
- 1 j 7 h
- PR mergées (30 j)
- 8
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Propose un modèle de pull request
- Aucun guide de contribution
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.
Autres issues de stackabletech/commons-operator
-
Difficulté 4/5 3-5 jours Accessibilité débutants 25/100
-
Difficulté 3/5 1-2 jours Accessibilité débutants 38/100
-
Difficulté 4/5 3-5 jours Accessibilité débutants 25/100
-
Dependency DashboardOuverte
Difficulté 2/5 1-3 heures Accessibilité débutants 15/100
-
Difficulté 3/5 1-2 jours Accessibilité débutants 35/100
stackabletech/commons-operator#235 · 1 commentaire ·
Toutes les issues de stackabletech/commons-operator
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
NousResearch/hermes-agent#136483 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 88/100
Les mainteneurs répondent en général sous 1 jour
-
[BUG] LazyStackedTensorDictStore zeroes the last byte of a new key set on the last elementPeut-être pris @peterdsharpe l’a pris aujourd’hui. Ouvertebug
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
pytorch/tensordict#2307 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour
-
GrokModel.generate/a_generate pass an OpenAI-style list-of-dicts to xai_sdk.chat.user(), so every call crashes with a protobuf TypeError before any network I/OPeut-être pris @Christian-Sidak l’a pris aujourd’hui. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
confident-ai/deepeval#3436 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour