[Feature] Set RevisionHistoryLimit on the generated Robin Deployment to bound retained ReplicaSets

Aperta Adatta ai principianti
  • Qualcosa non va?
#87 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
75/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go, kubernetes
Ambito
backend, cloud, devops

Direzione di ricerca

L’issue indica la funzione buildDesiredRobinDeployment in internal/controller/redkey_robin.go. Inizia esaminando la costruzione di DeploymentSpec in quel punto. Aggiungi un campo RevisionHistoryLimit impostato a 2, utilizzando una costante con nome. Aggiorna la funzione robinDeploymentNeedsUpdate affinché confronti questo campo per rilevare le discrepanze. Esegui i test unitari esistenti per verificare che venga applicato il valore predefinito e che la riconciliazione rimanga idempotente.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Problem

The operator builds the Robin Deployment in buildDesiredRobinDeployment (internal/controller/redkey_robin.go) without setting RevisionHistoryLimit, so Kubernetes applies its default of 10. Each rollout of the Robin Deployment (e.g. a spec.robin.image bump, args or template change) leaves an old, scaled-to-zero ReplicaSet behind, and up to 10 of them accumulate per cluster. For a singleton controller-style Deployment that changes rarely, keeping 10 historical ReplicaSets is unnecessary clutter in etcd and in kubectl get rs.

Proposed solution

Set RevisionHistoryLimit explicitly on the Robin Deployment spec to a small value (2), which still allows an immediate rollback to the previous revision without accumulating a long tail of empty ReplicaSets.

  • Default: RevisionHistoryLimit: 2.
  • Keep it overridable via spec.robin.template if/when that path exposes it (consistent with other defaults).

ProgressDeadlineSeconds was considered and intentionally left out of scope: the default (600s) is fine for a fast-starting single-replica Deployment, and lowering it adds little value. It can be revisited separately if rollout-stall alerting is ever needed.

Acceptance criteria

  • The generated Robin Deployment sets RevisionHistoryLimit: 2.
  • A user-supplied value via spec.robin.template (if exposed) overrides the default.
  • Drift detection (robinDeploymentNeedsUpdate) accounts for RevisionHistoryLimit so reconciliation stays idempotent (no patch loop).
  • Unit test asserts the default value is present on the generated Deployment.

Implementation notes

  • Add the field in buildDesiredRobinDeployment where the DeploymentSpec is constructed (internal/controller/redkey_robin.go), alongside Replicas/Selector/Template.
  • Use a named constant (e.g. robinRevisionHistoryLimit int32 = 2) for clarity.
  • Include the field in the set compared by robinDeploymentNeedsUpdate so an existing Deployment with the k8s default (10) is reconciled down to 2.

Related

  • Same function as the probes (B) and securityContext/resources (C) features — coordinate edits to buildDesiredRobinDeployment to avoid conflicts.
Lingua principale
Go
Stelle
29
Fork
2
Merge medio
13h 32m
PR unite (30g)
16

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di InditexTech/redkey-operator

Tutte le issue di InditexTech/redkey-operator

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.