CFP: Drop CRD versioning

[aanm]

Cilium Feature Proposal

Is your proposed feature related to a problem?

At the moment, Cilium Custom Resource Definition (CRD) are versioned with the value defined in https://github.com/cilium/cilium/blob/c0ae00df7d6753d8c1ffa5bb45ac004eb7b479e2/pkg/k8s/apis/cilium.io/register.go#L13-L18

This particular schema version was introduced when the cilium-agents had the task of either creating or updating the Cilium CRD. During an upgrade process, without a schema version, the cilium-agents couldn't determine whether to update the CRD or leave it unchanged. This is the reason why the schema version was introduced, as it enabled them to ascertain whether an update was needed.

Now, the responsibility for creating the CRD lies entirely with the Cilium Operator. Since there's only one entity in charge of this task, it might be worth considering eliminating the versioning of the CRD and simply installing the version provided by the Cilium Operator. This change would permit the ability to carry out downgrades of the CRD, as the current logic only updates the CRD if the versioning number is higher than the one available on the cluster.

[christarazi]

This can be a good-first-issue, right?

[joestringer]

I like that the CRD schema version provides a way to identify which CRD is configured. I think that we can achieve the same upgrade/downgrade feature by keeping the CRD schema version, but then by changing the Cilium Operator to just detect a version mismatch and unconditionally change the schema. In other words, today the operator enforces that the schema version must always increase. This proposal would be that the operator may allow downgrades of the schema version as well.

If we enable the above, then we could also consider aligning the schema version to the Cilium version. Instead of tracking the schema version differently from the Cilium version, we could update the schema version to exactly match the current Cilium version. This would simplify correlating the schema version to the Cilium version if someone needs to do this, and would also simplify the development/maintenance efforts around the schema version (remove docs updates for correlation, remove requirement for developers to consider schema version when modifying the schema). In this case, the schema should also support prereleases like v1.15.0-pre.1.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[github-actions[bot]]

This issue has not seen any activity since it was marked stale. Closing.