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 storageos2 and does not contain any version compatible with k8s 1.22/OCP 4.9. Following some findings by checking the distributions published:

• storageosoperator.v2.3.0: 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: (["jobs.storageos.com" "nfsservers.storageos.com" "storageosclusters.storageos.com" "storageosupgrades.storageos.com"])

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.

[ukd1]

Just hit this running 1.22 - not a great first time user experience:

k  create -f https://github.com/storageos/cluster-operator/releases/download/v2.4.4/storageos-operator.yaml
namespace/storageos-operator created
clusterrole.rbac.authorization.k8s.io/storageos-operator created
serviceaccount/storageoscluster-operator-sa created
deployment.apps/storageos-cluster-operator created
unable to recognize "https://github.com/storageos/cluster-operator/releases/download/v2.4.4/storageos-operator.yaml": no matches for kind "CustomResourceDefinition" in version "apiextensions.k8s.io/v1beta1"
unable to recognize "https://github.com/storageos/cluster-operator/releases/download/v2.4.4/storageos-operator.yaml": no matches for kind "CustomResourceDefinition" in version "apiextensions.k8s.io/v1beta1"
unable to recognize "https://github.com/storageos/cluster-operator/releases/download/v2.4.4/storageos-operator.yaml": no matches for kind "CustomResourceDefinition" in version "apiextensions.k8s.io/v1beta1"
unable to recognize "https://github.com/storageos/cluster-operator/releases/download/v2.4.4/storageos-operator.yaml": no matches for kind "CustomResourceDefinition" in version "apiextensions.k8s.io/v1beta1"
unable to recognize "https://github.com/storageos/cluster-operator/releases/download/v2.4.4/storageos-operator.yaml": no matches for kind "ClusterRoleBinding" in version "rbac.authorization.k8s.io/v1beta1"

[croomes]

Hi, we're replacing this project with https://github.com/storageos/operator which is compatible with v1.22. We should be releasing it soon.

[ukd1]

@croomes all your public docs point to this repo, and 1.22 has been out since early August, and these have been throwing warnings before they were removed. This wasn't / is not ideal first-time user experience for me, and I'm surprised.

[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]

HI croomes,

Could you make that clear in the Readme of this project and also if possible a description of your operator into the catalog? How your users will be aware of it?

Have you been distributing the other project on OCP? if yes, could you also publish compatible versions?

[camilamacedo86]

Hi @croomes ,

Be aware that: if you do not provide a workable solution via RedHat Connect asap:

• Your package/project will be removed from 4.9 catalog
• You cannot use replaces in your first publication made to add the project again on 4.9 when you publish the compatible version
• Your users cannot upgrade their cluster to use 4.9 with your solution installed then, they will need to stick on 4.8 or stop using your project to be able to move forward.

I would recommend you try to prioritize this one.

[croomes]

Hi @camilamacedo86, we are very close to releasing StorageOS v2.5.0 which is based on the new operator at https://github.com/storageos/operator. It is currently in beta.

How long do we have to release it before we're removed from the catalog?

cc @actionbuddha

[camilamacedo86]

Hi @croomes,

Hi @camilamacedo86, we are very close to releasing StorageOS v2.5.0 which is based on the new operator at https://github.com/storageos/operator. It is currently in beta.

A project that does not exist now in 4.9 pre-ga indexes cannot be removed. So, for the new project that does not apply at all.

How long do we have to release it before we're removed from the catalog?

This issue is about storageos2 package. This package has no compatible/workable solutions on 4.9 and then, before the 4.9 release, it will be removed from 4.9 if not provide any valid version with.

According to the https://connect.redhat.com/blog/api-deprecation-kubernetes-122-will-impact-your-operators you had up Sep 30. This time was extended until the latest Friday.

Note that you can always send new versions compatible with 4.9. However, the limitation here is that you will be unable to use replaces to publish in 4.9 and below. So, the easy way would be to publish asap a compatible version with 4.9 via RedHat Connect if you would like to still distribute solutions for the package storageos2.

[croomes]

@camilamacedo86 we'd planned to push the new operator (https://github.com/storageos/operator) to the operator2 package rather than creating a new project. We should be able to do this by the end of the week.

Hopefully that's the best approach?

[camilamacedo86]

HI @croomes,

Be aware that your first publication targeting OCP 4.9 (if not get in time) you cannot use the “replaces” configuration since any previous version published so far does not exist on 4.9 to be replaced. You can publish your new distribution using the skips or skipRange options instead of replaces. More info: https://v0-18-z.olm.operatorframework.io/docs/concepts/olm-architecture/operator-catalog/creating-an-update-graph/. If you have been using replaces I'd try to suggest you push asap.

All please see https://connect.redhat.com/blog/api-deprecation-kubernetes-122-will-impact-your-operators.