Extend kubectl get clusterdeployment output

[Josca]

Please extend the command output to improve user experience:

kubectl get clusterdeployment

Current

NAME       READY   STATUS
cluster1   True    ClusterDeployment is ready*
cluster2   True    ClusterDeployment is ready

• ClusterDeployment is ready should be just Ready
• Column SERVICES could show deployed/not deployed services counts.

Suggested

NAME       STATUS      SERVICES      AGE
cluster1   Processing  3/5           2d12h
cluster2   Ready       2/2           2d12h

[zerospiel]

Just a head-up, I won't change the generic status too much since it is unclear what is the status column and how to determine/distinguish processing/failed/starting from each other so I see it as (without the wide printing)

NAME       Ready      SERVICES      STATUS                        AGE
cluster1   False      3/5           Some error message            2d12h
cluster2   True       2/2           ClusterDeployment is Ready    2d12h

[Josca]

It makes sense to keep it consistent with standard kubernetes resources, as it makes it easier to work with. People will expect that. E.g. pods:

NAMESPACE              NAME                                                    READY   STATUS    RESTARTS      AGE
ingress-nginx          ingress-nginx-controller-6595c67df7-bxppq               1/1     Running   0             42h
kubecost               kubecost-cost-analyzer-85588967c8-df28w                 4/4     Running   4 (40h ago)   40h

... or deployments:

NAMESPACE              NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
ingress-nginx          ingress-nginx-controller               1/1     1            1           42h
kube-system            coredns                                1/1     1            1           42h

• So STATUS column (if contained) should provide some keyword and the meaning should be explained in k0rdent docs.
• READY column could contain "number of services in 'ready' state/ all services number". It will nicely correspond with pods and deployments READY column which all kubernetes users are familiar with.

Btw. I think it should cover all services running in the managed cluster (even those from MultiClusterService) to provide overall info about the cluster.

[zerospiel]

It makes sense to keep it consistent with standard kubernetes resources, as it makes it easier to work with. People will expect that

As of my knowledge, there ain't guidelines on what to put into the custom columns, because these are Custom Resource Definitions so the meaningfulness justifies all the column names and their values, not some other resources. If some of the column names are confused with the standard ones it is not a problem to rename them (e.g. Status may be confusing). For instance, if no services are given, then the 0/0 column value says nothing about whether a cluster is ready or not. As I have mentioned above there is no way to distinguish start/processing/stuck/readiness statuses from each.

So I would stick to the following (the pipes separate the wide output:

NAME       Ready      SERVICES   TEMPLATE   AGE      | ERRORS               DRYRUN         
cluster1   False      3/5        tpl1       2d12h    | Some error message   False         
cluster2   True       2/2        tpl2       2d12h    |                      False

I think it should cover all services running in the managed cluster (even those from MultiClusterService) to provide overall info about the cluster.

👍

[Josca]

@zerospiel it looks good. What about this improvement? I think it would be really cool.

NAME       READY     STATUS     SERVICES   TEMPLATE   AGE      | ERRORS               DRYRUN         
cluster1   0/3       Failed     0/0        tpl1       2d12h    | Some error message   False
cluster2   4/5       Pending    0/0        tpl2       2d12h    |                      False         
cluster3   3/3       Running    2/2        tpl3       2d12h    |                      False

• READY - shows number of running/total cluster nodes.
• STATUS - cluster status (is it being created, is it running - operating, did it failed).
  ...

[zerospiel]

I am struggling to understand how to determine the status, as I have mentioned above. For example, event a CAPI Cluster does not report such states (status) because it does not know whether the infra has or has not yet been provisioned. At this point, it is starting to look like the clusterctl describe CLI, and I am reluctant to do this. You could propose a dedicated PR implementing that part with ready and status columns and we could work it through together. I do not see the clusterdeployment as a part of appsv1 and corev1 so I wouldn't apply those concepts on a custom resource.