feat: enrich kubectl get output
#878
Conversation
by adding additional printer columns for number of desired workers, number of available workers, status, age, head Pod IP, and head Service IP. ## Before ``` kubectl get rayclusters NAME AGE dxia-test 53m keshi-test 2d23h ``` ## After ``` kubectl get rayclusters NAME DESIRED WORKERS AVAILABLE WORKERS STATUS AGE dxia-test 3 4 ready 60m keshi-test 1 2 ready 2d23h kubectl get rayclusters -o wide NAME DESIRED WORKERS AVAILABLE WORKERS STATUS AGE HEAD POD IP HEAD SERVICE IP dxia-test 3 4 ready 60m 10.169.4.130 10.160.217.214 keshi-test 1 2 ready 2d23h 10.169.6.102 10.160.218.91 ```
|
There's a bug with |
| //+kubebuilder:printcolumn:name="desired workers",type=integer,JSONPath=".status.desiredWorkerReplicas",priority=0 | ||
| //+kubebuilder:printcolumn:name="available workers",type=integer,JSONPath=".status.availableWorkerReplicas",priority=0 |
There was a problem hiding this comment.
I wanted to show something like Deployments' READY column with an available/desired in one column. But only simple field access is supported. Lmk if there's some way.
kubectl get deployments
NAME READY UP-TO-DATE AVAILABLE AGE
my-deployment 1/1 1 1 515d
There was a problem hiding this comment.
Neither do I. separate columns sounds good.
| //+kubebuilder:printcolumn:name="desired workers",type=integer,JSONPath=".status.desiredWorkerReplicas",priority=0 | ||
| //+kubebuilder:printcolumn:name="available workers",type=integer,JSONPath=".status.availableWorkerReplicas",priority=0 |
There was a problem hiding this comment.
Neither do I. separate columns sounds good.
in this screenshot, you expect 3 but there're 4? What's the pod status? |
Status is ready. It’s an existing bug. You can see it with kubectl get raycluster -o yaml. See comment above. Controller is counting head as a worker, I think. |
There was a problem hiding this comment.
Thank @davidxia for the contribution! I tried to test this PR manually, and found that STATUS and HEAD POD IP do not print any message when all head Pod and worker Pod are READY and RUNNING. Is it an expected behavior? Thanks!
# Step 1: Create a Kind cluster
kind create cluster
# Step 2: Build a docker image
# (path: kuberay/ray-operator)
make docker-image
kind load docker-image controller:latest
# Step 3: Install a KubeRay operator with the docker image built in Step 2.
# (path: kuberay/helm-chart/kuberay-operator)
helm install kuberay-operator --set image.repository=controller,image.tag=latest .
# Step 4: Install a RayCluster
# (path: kuberay/helm-chart/ray-cluster)
helm install raycluster .
# Step 5: See the following figure.
kubectl get rayclusters.ray.io
kubectl get rayclusters.ray.io -o wide
Yes this is expected in some cases. The printer columns simply access fields in the underlying RayCluster custom resource. Sometimes I think it's OK to show an empty cell for a column if there isn't a value for it yet. #875 marks clusters as pending if they aren't ready yet. Lmk what you think of that separate issue. |
kuberay/ray-operator/controllers/ray/raycluster_controller.go Lines 865 to 867 in cbe1865 Based on the code snippet above, the State should be I check it again, and all Pods are running and ready as shown in the following figure.
Is it related to #882? |
yes
yes, your RayClusters will more reliably be marked |
|
The CI failure is due to #852. Merge it. |
|
amazing, thanks! Looking forward to some enriched output in the next release 🙌 |
by adding additional printer columns for number of desired workers, number of available workers, status, age, head Pod IP, and head Service IP.
by adding additional printer columns for number of desired workers, number of available workers, status, age, head Pod IP, and head Service IP.
Before
After
Checks