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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#87 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
75/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go, kubernetes
Área
backend, cloud, devops

Línea de trabajo

El issue señala la función buildDesiredRobinDeployment en internal/controller/redkey_robin.go. Empieza examinando la construcción de DeploymentSpec allí. Añade un campo RevisionHistoryLimit establecido en 2, utilizando una constante con nombre. Actualiza la función robinDeploymentNeedsUpdate para que compare este campo al detectar desviaciones. Ejecuta las pruebas unitarias existentes para asegurarte de que se aplique el valor predeterminado y la reconciliación siga siendo idempotente.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Go
Estrellas
29
Forks
2
Merge medio
13 h 32 min
PR fusionados (30 d)
16

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de InditexTech/redkey-operator

Todos los issues de InditexTech/redkey-operator

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.