Add a description field to GatewayClass

[robscott]

What would you like to be added:
An optional, short, description field (<60 characters) could help describe a GatewayClass with a bit more detail. This concept was inspired by @youngnick's doc that included a suggestion for some extra information about a GatewayClass.

Why is this needed:
GatewayClass names are intentionally brief and don't always provide sufficient context. For example, clarifying that a class was implemented by a cloud load balancer or in-cluster proxy could be helpful.

[youngnick]

I think this change should also add this description field to the default columns for the CRD (so you see it with kubectl get).

[hzliangbin]

/assign

[hzliangbin]

@robscott hi, may I take it if possible?

[robscott]

Hey @hzliangbin, thanks for offering to take this on! You're very welcome to make a PR to add this. One note though, I don't think we've reached full consensus on this yet, so there's no guarantees that this field will be added, it's just something that I think would be a good idea.

@hbagdi, @danehans, or @jpeach do you have any hesitations about adding a description field to GatewayClass?

[hbagdi]

+1 on adding this.

[hzliangbin]

@robscott got it

[jpeach]

@hbagdi, @danehans, or @jpeach do you have any hesitations about adding a description field to GatewayClass?

Is there precedent for this in other class-oriented APIs?

[jpeach]

Also, you can do this with an annotation today. Does it really need to be a first-class field? Is the problem of wanting some business or contextual description specific to Gateway or is it generally applicable to Kubernetes resources?

[youngnick]

I don't think it needs to be a first-c,lass field. But I can't see another way to make a simple thing that early adopters can use to get a little more information about a GatewayClass without installing extra tooling, checking annotations, or other similar things. This is literally just to give people the option to end up with something like this from kubectl get output:

$> kubectl get gatewayclass
NAME       CONTROLLER                            DESCRIPTION
internal   acme.io/gateway-controller-internal   For non-internet-facing Gateways.
external   acme.io/gateway-controller-external   For internet-facing Gateways

There's no way to specify that kubectl get returns the value for specific annotations. Should this information be in an annotation? Probably. Does having it in an annotation let us do this without extra tooling? Nope.

Does this constitute another argument for supplying a kubectl plugin for dealing with Gateway APIs? Maybe.

[jpeach]

I'm pretty surprised that StorageClasses don't seem to have a way to do this, but I wasn't able to dig up any issues asking for it 🤷

[bowei]

I support this change, as it is fairly benign given it is entirely non-semantic in nature and really improves the CRD ergonomics.

[mark-church]

Great to see the progress on this issue - this will be a very helpful UX improvement!

[hbagdi]

Done in #653
/close

[k8s-ci-robot]

@hbagdi: Closing this issue.

In response to this:

Done in #653
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.