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

Đang mở
  • Có gì không ổn?
#124 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go, kubernetes, redis
Lĩnh vực
backend, devops

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Go
Star
29
Fork
2
Merge trung bình
13 giờ 32 phút
Pull request đã merge (30 ngày)
16

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của InditexTech/redkey-operator

Tất cả issue của InditexTech/redkey-operator

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.