Removal of v1alpha5 apiversion

[kashifest]

Motivation

v1alpha5(v0.5.x) apiVersion have been EOL since September 2022 and the equivalent CAPI apiVersion v1alpha4(v0.4.x) has been EOL since April 2022. It is now a good time to plan to remove v1alpha5.

Proposal

We can follow the following timeline:

• Release v1.5:
  • Announce removal of apiVersion in v1.6 & v1.7
• Release v1.6:
  • Kubernetes API server will stop serving v1alpha5
    • We will set served to false for the apiVersion in all our CRDs.
    • Then users can’t read or write with the old apiVersion anymore.
    • The API server will still be able to read and convert the old apiVersion.
    • If necessary, users can easily enable the apiVersion again by reverting served back to true on the CRD.
• Release v1.7:
  • Remove v1alpha5 apiVersion
    • Drop all code related to v1alpha5 (API types, conversions, tests, …)
    • If we get feedback that folks need more time to migrate we can discuss delaying this stage by another minor release to give folks more time.

Tasks

• Open a PR to document removal plan
• Check with CAPI maintainers if providers also need to implement changes as they have done in CAPI controllers should keep ownerRefs on the current apiVersion kubernetes-sigs/cluster-api#7224 and 🌱 MachinePool: automatically bump apiVersions like in our other controllers kubernetes-sigs/cluster-api#7995.

v1.5:

• Mark v1alpha5 apiVersion and Go API types as deprecated
• Release notes should highlight the imminent removal of the apiVersion in v1.6 & v1.7

v1.6:

• Stop serving v1alpha5 via kubebuilder:unservedversion
• Release notes should reflect the changes

v1.7:

• Drop all code related to v1alpha5 (API types, conversion, …)
  • Wait a bit for feedback after v1.6
• Release notes should reflect the changes

Misc:

• Upgrade tests should be updated to cover v1.1 => v1.latest:
• Document upgrade test coverage

/kind cleanup

[Rozzii]

/triage accepted

[metal3-io-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues will close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[lentzi90]

/remove-lifecycle stale

[kashifest]

/assign @kashifest

[MaxRink]

Youre propably also going to hit kubernetes-sigs/cluster-api#10051 with this

[Rozzii]

/cc @adilGhaffarDev
@adilGhaffarDev has commented on kubernetes-sigs/cluster-api#10051 thus linking it with kubernetes-sigs/cluster-api#9688 FYI. I guess this requires a CAPI side fix anyways .

[adilGhaffarDev]

@adilGhaffarDev has commented on kubernetes-sigs/cluster-api#10051 thus linking it with kubernetes-sigs/cluster-api#9688 FYI. I guess this requires a CAPI side fix anyways .

Yes, let's keep the alpha APIs until we have a fix from CAPI side. We don't need e2e tests since this scenario is already tested in CAPI e2e.

[kashifest]

@adilGhaffarDev actually this issue is done, since we removed the API already, I forgot to update it, can you describe a bit more in detail whats the issue here since in the removal of API PR we agreed that it should not affect us #1525 (comment). Also from community side we dont have any issue reported yet on this so we can safely assume no one was using the v1a5 API?

[kashifest]

This issue is good to close since the API is removed already, if we see any further issues I suggest we create a separate issue for that.
/close

[metal3-io-bot]

@kashifest: Closing this issue.

In response to this:

This issue is good to close since the API is removed already, if we see any further issues I suggest we create a separate issue for that.
/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.