Add more columns to CRDs

[howardjohn]

What would you like to be added:
We should add more columns to the CRDs to expose useful information in kubectl. For example, we can expose Admitted for most types:

$ k get gc
NAME    CONTROLLER                    ADMITTED
istio   istio.io/gateway-controller   True

I would also suggest adding AGE to align with most other k8s types.
Why is this needed:
Useful to expose info here.

[howardjohn]

Related: #586

[robscott]

Agree that this would be great to have. #592 adds a "Created At" column, but I think "Admitted" is going to be more difficult here. Unfortunately additionalPrinterColumns just does not handle status conditions (or other lists) well. We could follow the same approach I proposed in #587 and add a new field to status just to improve kubectl get output. Alternatively we could push to get better support built into upstream. Of course if this API itself ever does end up becoming built into k/k, many of these problems would go away on their own.

[howardjohn]

You can do it with .status.conditions[?(@.type=="Admitted")].status

Also can do it directly like kubectl get gatewayclass -o 'custom-columns=NAME:.metadata.name,HEALTHY:.status.conditions[?(@.type=="Admitted")].status'

For the ones that are nested (listener status) I don't know how to handle though.

[robscott]

@howardjohn Unfortunately I haven't been able to get that to work for additionalPrinterColumns. It seems that the implementation between custom-columns in kubectl and additionalPrinterColumns is quite different. For example, running this works:

kubectl get gateway -o'custom-columns=NAME:metadata.name,TEST:.spec.listeners[?(@.protocol=="HTTP")].routes.selector'

but unfortunately adding the same logic to additionalPrinterColumns just returns empty. I've seen this kind of similar pattern for anything other than a simple path lookup.

[howardjohn]

Hm.. it seems like cert-manager is doing this: https://github.com/jetstack/cert-manager/pull/1194/files#diff-4cd218a9d6c5b00138ca643ec6b983015ba906cff00011340e798d668b9dfa39R27. Not sure what the gap is. The additionalPrinterColumns stuff is a bit frustrating

[robscott]

I think one of the best solutions that's been proposed so far involves a mutating webhook that populates new fields just for kubectl output. That would allow us the ability to customize all output with a great deal of control. Of course there's a lot of overhead in a webhook. With the recent ReferencePolicy addition, it's clear that more output fields would be helpful there as well, but since it's essentially two lists of structs, it's very difficult without something like a webhook.

More info and discussion is in #629.

[shaneutt]

While grooming we saw that this one was open for a long period of time without anyone with a strong use case to champion it. We're going to close this as we don't expect anyone's ready to drive it forward, but if you still want this feature and have a strong use case we will be happy to reconsider this and re-open.