Operator projects using the removed APIs in k8s 1.22 requires changes.

[camilamacedo86]

Problem Description

Kubernetes has been deprecating API(s), which will be removed and are no longer available in 1.22. Operators projects using these APIs versions will not work on Kubernetes 1.22 or any cluster vendor using this Kubernetes version(1.22), such as OpenShift 4.9+. Following the APIs that are most likely your projects to be affected by:

• apiextensions.k8s.io/v1beta1: (Used for CRDs and available since v1.16)
• rbac.authorization.k8s.io/v1beta1: (Used for RBAC/rules and available since v1.8)
• admissionregistration.k8s.io/v1beta1 (Used for Webhooks and available since v1.16)

Therefore, looks like this project distributes solutions via the Red Hat Connect with the package name as ako-operator and does not contain any version compatible with k8s 1.22/OCP 4.9. Following some findings by checking the distributions published:

• ako-operator.v1.4.2: this distribution is using APIs which were deprecated and removed in v1.22. More info: https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22. Migrate the API(s) for CRD: (["akoconfigs.ako.vmware.com"]),ClusterRole: (["ako-operator-metrics-reader"]),

NOTE: The above findings are only about the manifests shipped inside of the distribution. It is not checking the codebase.

How to solve

It would be very nice to see new distributions of this project that are no longer using these APIs and so they can work on Kubernetes 1.22 and newer and published in the Red Hat Connect collection. OpenShift 4.9, for example, will not ship operators anymore that do still use v1beta1 extension APIs.

Due to the number of options available to build Operators, it is hard to provide direct guidance on updating your operator to support Kubernetes 1.22. Recent versions of the OperatorSDK greater than 1.0.0 and Kubebuilder greater than 3.0.0 scaffold your project with the latest versions of these APIs (all that is generated by tools only). See the guides to upgrade your projects with OperatorSDK Golang, Ansible, Helm or the Kubebuilder one. For APIs other than the ones mentioned above, you will have to check your code for usage of removed API versions and upgrade to newer APIs. The details of this depend on your codebase.

If this projects only need to migrate the API for CRDs and it was built with OperatorSDK versions lower than 1.0.0 then, you maybe able to solve it with an OperatorSDK version >= v0.18.x < 1.0.0:

$ operator-sdk generate crds --crd-version=v1
INFO[0000] Running CRD generator.
INFO[0000] CRD generation complete.

Alternatively, you can try to upgrade your manifests with controller-gen (version >= v0.4.1) :

If this project does not use Webhooks:

$ controller-gen crd:trivialVersions=true,preserveUnknownFields=false rbac:roleName=manager-role paths="./..."

If this project is using Webhooks:

1. Add the markers sideEffects and admissionReviewVersions to your webhook (Example with sideEffects=None and admissionReviewVersions={v1,v1beta1}: memcached-operator/api/v1alpha1/memcached_webhook.go):

2. Run the command:

$ controller-gen crd:trivialVersions=true,preserveUnknownFields=false rbac:roleName=manager-role webhook paths="./..."

For further info and tips see the blog.

Thank you for your attention.

[camilamacedo86]

Hi, would we have any update on this?

See that we are very close to the release data and fix the projects seems not very hard. See how to fix it in the first comment. Then, would be great to be able to check a new version of your project distributed which is compatible with 4.9.

[camilamacedo86]

c/c @hemantavi

[hemantavi]

Hi @camilamacedo86, thanks for bringing this to our attention. Will upgrade the versions and push the changes to the existing operator in Red Hat Connect.

[camilamacedo86]

Hi @hemantavi,

I would like to recommend you folks prioritize it to ensure that your solution will be on 4.9 when the OCP version be released.

[hemantavi]

Hi @camilamacedo86 ,
The AKO Operator 1.4.2 is stale right now since it uses AKO v1.4.2 (which was released three months back).As far as we know, there are no users of the AKO Operator 1.4.2 today, on openshift.

The bundle image for AKO Operator 1.4.2 is labelled with:

LABEL com.redhat.openshift.versions="v4.5,v4.6"

Do you think whether this label is sufficient to prevent users from installing it on OCP 4.9?

We plan to release AKO operator v1.5.2 by 25th October which would use the recently released AKO 1.5.2. While the CRD version upgrade change is done, we also have to make certain changes to the AKO operator's controller code for 1.5.2. Do you think it would be prudent to prioritize 1.5.2 release of the AKO operator, since, re-pushing the AKO Operator bundle for 1.4.2 would be an unnecessary effort.

[camilamacedo86]

Hi @hemantavi,

The syntax:

LABEL com.redhat.openshift.versions="v4.5,v4.6"

It means to install in all versions from 4.6. Also, the syntax with "(coma)" should no longer be used.
That isn't very clear. See: https://redhat-connect.gitbook.io/certified-operator-guide/ocp-deployment/operator-metadata/bundle-directory/managing-openshift-versions

We will try to help out as much as possible and are technically available for the previous cases, so do not worry.
However, if you want to publish still versions that should be published on previous OCP versions < 4.9 and does not work on 4.9, you must use max OCP version annotation not to allow your users to upgrade from 4.8 to 4.9 with this version installed as well, please read https://docs.openshift.com/container-platform/4.8/operators/operator_sdk/osdk-working-bundle-images.html#osdk-control-compat_osdk-working-bundle-images.

Do you think it would be prudent to prioritize the 1.5.2 release of the AKO operator, since re-pushing the AKO Operator bundle for 1.4.2 would be an unnecessary effort.

The easy/better way is you provide a workable solution on 4.9 asap. Maybe a new version such as 1.5.0 only with the upgrade for CRDs. Note that the ETA to accomplish this goal passed already, and if you cannot do that soon enough, then the limitation is that you cannot use the replaces config for your first publication on 4.9. See: https://connect.redhat.com/blog/api-deprecation-kubernetes-122-will-impact-your-operators

[swathinsankaran]

@DixitAakash could you please check this?