⚠️ Remove v1alpha3 and v1alpha4

[mdbooth]

Which issue(s) this PR fixes:
Fixes #1326

Special notes for your reviewer:
This PR relies on behaviour in clusterctl which updates storage versions on upgrade.

/hold

[netlify]

✅ Deploy Preview for kubernetes-sigs-cluster-api-openstack ready!

Name	Link
🔨 Latest commit	b1bb18b
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-sigs-cluster-api-openstack/deploys/645275745703e200081b8833
😎 Deploy Preview	https://deploy-preview-1527--kubernetes-sigs-cluster-api-openstack.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[tormath1]

any chance to remove this too:

cluster-api-provider-openstack/.golangci.yml

Lines 175 to 178 in 17d3f36

	# Can be drop once kubernetes-sigs/cluster-api-provider-openstack#1326 is done.
	- linters:
	- staticcheck
	text: "SA1019"

?

[mdbooth]

Added as a second commit.

[tormath1]

Looks good, CI lint is passing. 👌

[seanschneeweiss]

Keeping compatibility for that many revisions of the API of course is a pain and should be minimized. So thanks beforehand for working on this.

Two thoughts on this:

• Looking at CAPI, where they did almost the same for their Alpha versions. CAPI deprecated the API before removing it. kubernetes-sigs/cluster-api#8071. Should we deprecate first and then remove - regardless the fact, that this is an alpha API version? From src:

  Alpha API versions may be removed in any release without prior deprecation notice

• Should we adapt kubernetes-sigs/cluster-api#8038?
  Especially this part

• We will set served to false for the apiVersions in all our CRDs.
• Then users can’t read or write with the old apiVersions anymore.
• The API server will still be able to read and convert the old apiVersions.
• If necessary, users can easily enable the apiVersions again by reverting served back to true on the CRD.

[seanschneeweiss]

This might need modification too:

cluster-api-provider-openstack/config/crd/kustomization.yaml

Lines 1 to 3 in 17d3f36

	commonLabels:
	cluster.x-k8s.io/v1alpha3: v1alpha3
	cluster.x-k8s.io/v1beta1: v1alpha4_v1alpha5_v1alpha6_v1alpha7

[mdbooth]

Keeping compatibility for that many revisions of the API of course is a pain and should be minimized. So thanks beforehand for working on this.

Two thoughts on this:

• Looking at CAPI, where they did almost the same for their Alpha versions. CAPI deprecated the API before removing it. 🌱 Deprecate v1alpha3 & v1alpha4 cluster-api#8071. Should we deprecate first and then remove - regardless the fact, that this is an alpha API version? From src:

  Alpha API versions may be removed in any release without prior deprecation notice

• Should we adapt Removing v1alpha3 & v1alpha4 apiVersions cluster-api#8038?
  Especially this part

• We will set served to false for the apiVersions in all our CRDs.
• Then users can’t read or write with the old apiVersions anymore.
• The API server will still be able to read and convert the old apiVersions.
• If necessary, users can easily enable the apiVersions again by reverting served back to true on the CRD.

I think this is the important discussion, and I'm ambivalent.

I am inclined to say lets get these 2 specifically gone and do better in the future. The reasons are:

• We haven't effectively tested these versions in a long time. I have little confidence they still work.
• Anybody who upgraded to v0.7 is no longer running them anyway.
• Anybody who skips directly to v0.8 can recover by downgrading to v0.7, waiting for the upgrade to complete, then upgrading to v0.8 again. We need to ensure this is in the 0.8 release notes, though.
• We're making the continued modification of the current API more burdensome by keeping them.

However, I appreciate this is a bullish view and I could easily be persuaded otherwise.

In the spirit of 'do better in the future', though, I wonder if we should immediately deprecate v1alpha5 and v1alpha6 with a target of setting 'unserved' in v0.9 and removal in 'v0.10'?

[jichenjc]

In the spirit of 'do better in the future', though, I wonder if we should immediately deprecate v1alpha5 and v1alpha6 with a target of setting 'unserved' in v0.9 and removal in 'v0.10'?

is this CAPI or other provider should consider already? we may not be identical to them but reference should be helpful

anyway, I think your statement is reasonable and we want folks to keep upgrade to save effort with lower API version maintainance

[mdbooth]

I've added this to the agenda of this week's office hours. Lets make a decision on this by the end of this week at the latest.

[tormath1]

@mdbooth the documentation/readme is not updated at the moment:

cluster-api-provider-openstack/README.md

Line 36 in 1b32291

## Compatibility with Cluster API and Kubernetes Versions

[mdbooth]

/hold cancel

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mdbooth, mnaser, seanschneeweiss

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mdbooth,seanschneeweiss]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[jichenjc]

/lgtm

thanks for the update