Remove deprecated v1alpha1 CRDs #6162
Conversation
220920c to
f9a0316
Compare
| @@ -81,3 +80,4 @@ These are the API group versions which are currently available when using Antrea | |||
| | CRD | CRD version | Introduced in | Deprecated in | Removed in | | |||
| |---|---|---|---|---| | |||
| | `ClusterGroup` | v1alpha2 | v1.0.0 | v1.1.0 | v2.0.0 | | |||
| | `Tier` | v1alpha1 | v1.0.0 | v1.13.0 | v2.0.0 | | |||
There was a problem hiding this comment.
We didn't have such a long time window between deprecation and removal for this one.
However, it was an Alpha API and we are upgrading to Antrea v2 so that's ok by me. I think we also agreed on this removal when we first started discussing Antrea v2 and bumping up Alpha APIs to Beta.
Adding @tnqn for his opinion.
My only concern would be a user upgrading from an older Antrea version (e.g. 1.11) to Antrea v2.0. In this case, the v1beta1 version of API didn't exist in v1.11, so antctl upgrade api-storage cannot be used. My assumption would be that direct upgrade to v2.0 would not be possible in this case, and that users would need to upgrade to an intermediate version (1.13, 1.14, or 1.15) first. The fact that the 2 API resources are technically the "same" (conversion strategy is None) should be irrelevant here.
I am also tagging @edwardbadboy. We should make sure that the inability to directly upgrade from 1.11, 1.12 to Antrea v2 will not be an issue before we can merge this.
If we do remove this API, I assume we will also remove v1alpha3.ClusterGroup?
There was a problem hiding this comment.
Thanks for tagging me here. I think it not an issue to upgrade to an intermediate version first, for example 1.11 -> 1.13, 1.11 -> 1.15, then upgrade to 2.0 or 2.1.
There was a problem hiding this comment.
We commit "Antrea upgrades to a new release up to 4 minor versions newer", but this is a major version so I assume it's fine. Before releasing v2.0, we should perhaps confirm which path is supported and document a best practice. It seems we could allow 1.13 and above upgrade to 2.0, which sounds not bad.
There was a problem hiding this comment.
Yes, we should document this before the v2 release
There was a problem hiding this comment.
I just found Tier is not the only case, now I wonder why we remove Tier alone and keep other resources of the same situation, including NetworkPolicy, ClusterNetworkPolicy, ClusterGroup and Group. Was Tier marked for removal in 2.0 by accident?
There was a problem hiding this comment.
My understanding (based on #4832) is that at least there was agreement to remove all deprecated Alpha APIs as part of Antrea v2 (along with all Beta APIs which were deprecated at least 9-12 months ago). Has this changed?
Not sure why Tier was treated differently in the doc, but I wouldn't read too much into it.
There was a problem hiding this comment.
I don't know anything changed, then we should also remove v1alpha1 of NetworkPolicy, ClusterNetworkPolicy, ClusterGroup and Group.
There was a problem hiding this comment.
Yes, we should. @luolanzone perhaps it would make more sense to do all of them at once, although I am also fine with an individual PR for each API?
There was a problem hiding this comment.
Sure, I can remove all v1alpha1 CRD in this PR. I forgot that we have an agreement to remove all v1alpha1 CRDs. This PR is to based on the discussion here #6089 (comment). I was trying to make the change consistent with api.md. I will remove all v1alpha1 and the api.md as well.
There was a problem hiding this comment.
Either approach works for me.
Signed-off-by: Lan Luo <luola@vmware.com>
5efbb22 to
e83de5b
Compare
e83de5b to
e5fa5e6
Compare
Signed-off-by: Lan Luo <luola@vmware.com>
Signed-off-by: Lan Luo <luola@vmware.com>
e5fa5e6 to
4f5b7f7
Compare
|
/test-all |
This is a direct follow-up to antrea-io#6162. The PR removed some deprecated APIs but forgot to update the CRD declarations. The affected APIs are v1alpha1.ClusterNetworkPolicy, v1alpha1.NetworkPolicy, v1alpha1.Traceflow. Signed-off-by: Antonin Bas <antonin.bas@broadcom.com>
This is a follow-up to antrea-io#6162 We remove the following APIs in preparation for Antrea v2: v1alpha3.ClusterGroup, v1alpha3.Group, v1alpha2.ExternalIPPool. All 3 of them are Alpha APIs which have been deprecated since Antrea v1.13. Signed-off-by: Antonin Bas <antonin.bas@broadcom.com>
This is a follow-up to antrea-io#6162 We remove the following APIs in preparation for Antrea v2: v1alpha3.ClusterGroup, v1alpha3.Group, v1alpha2.ExternalIPPool. All 3 of them are Alpha APIs which have been deprecated since Antrea v1.13. Signed-off-by: Antonin Bas <antonin.bas@broadcom.com>
This is a follow-up to antrea-io#6162 We remove the following APIs in preparation for Antrea v2: v1alpha3.ClusterGroup, v1alpha3.Group, v1alpha2.ExternalIPPool. All 3 of them are Alpha APIs which have been deprecated since Antrea v1.13. Signed-off-by: Antonin Bas <antonin.bas@broadcom.com>
* Remove left over versions from CRD declarations This is a direct follow-up to #6162. The PR removed some deprecated APIs but forgot to update the CRD declarations. The affected APIs are v1alpha1.ClusterNetworkPolicy, v1alpha1.NetworkPolicy, v1alpha1.Traceflow. * Use existing versions in admission webhooks Signed-off-by: Antonin Bas <antonin.bas@broadcom.com>
* Remove additional deprecated CRD APIs This is a follow-up to #6162 We remove the following APIs in preparation for Antrea v2: v1alpha3.ClusterGroup, v1alpha3.Group, v1alpha2.ExternalIPPool. All 3 of them are Alpha APIs which have been deprecated since Antrea v1.13. * Remove invalid usage of v1alpha2.ExternalIPPool in e2e tests It should have been v1beta1 * Remove v1alpha2.Egress API While the API was not officially marked as deprecated in the documentation (docs/api.md), we did mention its deprecation in the CHANGELOG for the 1.13 release. It makes sense to delete this API at the same time as the other deprecated Alpha APIs, for Antrea 2.0. --------- Signed-off-by: Antonin Bas <antonin.bas@broadcom.com>
Remove deprecated CRDs including: