Would version reporting of CRDs e.g. gateway related CRDs versions (v1beta1 vs v1alpha2, etc) be beneficial?

[pmalek]

While working on k8sObjectCount provider I figured that some resources like custom CRDs might have different versions and reporting of those version might be beneficial for telemetry purposes. So instead of reporting only the raw count of object we'd report also the versions of those.

WDYT @Kong/team-k8s ?

[mflendrich]

Alternative: enforce the newest available version (that maintains backwards compatibility) on startup.

[shaneutt]

I don't want to see us taking on a policy of enforcing the latest version of an API primarily to ease telemetry implementations. It's a valid use case for most of this year to use v1alpha1.Gateway despite v1beta1.Gateway being available and I think having awareness about this (rather than right now trying to enforce a policy to disallow it) is valuable.

[mflendrich]

I generally agree with your point @shaneutt.
There seems to be some ambiguity, though, so let me clarify: I'm not advocating for forcing the user to use some specific API version when interacting with the k8s cluster.
What I'm advocating for is that the latest version of the CRD (known at the moment of release) be present and installed in the cluster - with alongside all the previous versions. The user would be free to use whatever version, as long as it's defined in the latest CRD.

This discussion makes me think that we're in fact considering two separate problems:

• what is the version of the CRD that the user has installed in the cluster
• what is the apiversion that the user uses to interact with the cluster.

[shaneutt]

How do you propose to enforce this?

[pmalek]

I'm not sure I understand what does it mean/the consequences of interacting with the cluster with a different version (I guess that's the version in the manifests applied) than having a particular version installed in the cluster.

The intention normally is to use the latest installed in the cluster when e.g. cluster has v1beta1 but user applies a manifest with v1alpha2: then v1beta1 should be used (as that's the only thing that cluster knows anyway). But what can go wrong in such scenario?

How do you propose to enforce this?

One could query the API for all GVKs in the cluster on startup. The second part is already done since we have watches set on particular versions of resources. (or this doesn't work the way I think it does 🤔).

[mflendrich]

I'm not sure I understand what does it mean/the consequences of interacting with the cluster with a different version (I guess that's the version in the manifests applied) than having a particular version installed in the cluster.

Reading material: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/

Example CRD with multiple versions defined: Gateway

[shaneutt]

I think CRD version checking is a good thing. At least one specific use case already exists: there could be users out there using v1alpha1.Gateway right now. It would be helpful to know if they continue to use the older version of the Gateway which is technically supported for a time, even when v1beta1.Gateway is now available.

[pmalek]

That would contradict @mflendrich's idea 😢

[shaneutt]

Yes, I'll address it over there.