[Feature] Add Age and Health columns to kubectl get redkey

Abierto
  • ¿Algo no está bien?
#124 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
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go, kubernetes, redis
Área
backend, devops

Línea de trabajo

Read the CRD printer column markers and the status aggregation path, especially aggregateStatus and computePhaseFromConditions, which the issue names. Add the Age and Health columns and determine how the existing conditions map to the proposed health values; move Ephemeral and PurgeKeys to priority 1. Done when generated CRDs expose the requested default columns and health reflects the aggregated data-plane conditions.

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

Descripción

Feature description

Redkey already ships shortNames: [rk] (rkc for RedkeyConfig) and 11 printer columns, so this is not a "missing shortName" request. It is about two columns that are missing today and cost nothing to add:

1. Age — there is no age at all. kubectl does not add AGE to custom resources; it only appears if the CRD declares it. Right now kubectl get rk cannot tell you whether a cluster was created five minutes or five months ago.

// +kubebuilder:printcolumn:name="Age",type="date",priority=0,JSONPath=".metadata.creationTimestamp",description="Time since the Redkey was created"

2. Health — the data-plane state is invisible. Phase (Ready / Configuring / Error) only reflects whether the desired config was applied. The operator already aggregates Healthy, MembershipHealthy, SlotsCovered, SlotsBalanced, ReplicasBalanced and ClusterCheckPassing onto the Redkey, but they live in status.conditions, which is a list — and printer columns are server-side JSONPath, which cannot filter a list item by type. Net effect: a cluster can be Ready while the health reconciler is actively healing or rebalancing, and kubectl get rk says nothing about it.

Proposal: materialise the rollup as a scalar status.health (Healthy | Degraded | Reconciling | Unknown), computed where the conditions are already aggregated (aggregateStatus → next to computePhaseFromConditions), and print it:

// +kubebuilder:printcolumn:name="Health",type="string",priority=0,JSONPath=".status.health",description="Data-plane health: Healthy, Degraded, Reconciling, or Unknown"
Result

Verified against a real apiserver (envtest 1.33, kubectl 1.35) with the CRDs generated from main@4cd6b8a:

$ kubectl get rk                      # today
NAME             MODE      PRIMARIES   REPLICAS   EPHEMERAL   PURGEKEYS   PHASE
cache-prod       cluster   3           1          false       false       Ready
cache-sessions   cluster   3           0          true        true        Configuring

$ kubectl get rk                      # with Age + Health
NAME             AGE   MODE         PRIMARIES   REPLICAS   PHASE         HEALTH
cache-prod       1s    cluster      3           1          Ready         Healthy
cache-scratch    1s    standalone   1           0          Ready         Degraded
cache-sessions   1s    cluster      3           0          Configuring   Reconciling

The default view keeps the same width as today (79 chars in the header with sample data): Age and Health come in, and Ephemeral / PurgeKeys move to priority=1 — they are spec knobs, not state.

Notes
  • Related: #120 asks for a kstatus-compatible status contract. This one is narrower — surfacing what already exists (status.conditions) in kubectl get, without changing the rollout semantics.
  • status.health is additive, no migration needed. An in-place CRD upgrade with kubectl apply --server-side keeps rk and adds the columns (verified: shortNames, categories and printer columns are mutable).
  • If you would rather not add a status field, the information is reachable client-side only, with -o custom-columns (that resolves JSONPath in the client, so filters work there): 
    $ kubectl get rk -o custom-columns=NAME:.metadata.name,HEALTH:.status.health,READY:.status.conditions[?(@.type=="Ready")].status
NAME             HEALTH        READY
cache-prod       Healthy       True
cache-scratch    Degraded      True
cache-sessions   Reconciling   <none>
    That is not usable in additionalPrinterColumns, hence the scalar.
Optional extras (drop them if you want a minimal change)

Same change, secondary value — all priority=1 except the last two, so they only affect -o wide:

  • Image ← .spec.image: fleets running several Redis versions; spec.version is empty in every sample, so it does not help.
  • StorageClass ← .spec.storageClassName: immutable via CEL, so a wrong value means recreating the cluster.
  • LastSeen ← .status.lastUpdatedAt: distinguishes "still reconciling" from "stuck". Age cannot tell you that.
  • categories: [redis] in +kubebuilder:resource → enables kubectl get redis.
  • Typo in the DeletePVC column description: "Deleve PVC" → "Delete PVC".

Deliberately not proposed:

  • A READY 3/3 nodes column: status.nodes does not distinguish "joined" from "ready", so the counter would lie until the Robin-side semantics are confirmed.
  • Renaming the Replicas column: it reads spec.replicasPerPrimary, while status.replicas (scale subresource) counts primaries. Ambiguous, but renaming is a visible change for anyone parsing the column, so it is left out.
Use case or motivation

kubectl get rk is the first command on-call runs, and today it cannot distinguish "config applied and healthy" from "config applied but degraded / rebalancing" — the exact distinction the health conditions were added for — nor how old a cluster is. Both are one-line changes (plus the small status rollup for Health), and neither widens the default view.

Would you like to work on this?

Yes, I'd like to open a PR.

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.