search

kubeflow / spark-operator

Kubernetes operator for managing the lifecycle of Apache Spark applications on Kubernetes.
Apache License 2.0
2.77k stars 1.38k forks source link

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

Closed camilamacedo86 closed 2 years ago

camilamacedo86 commented 3 years ago

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:

Therefore, looks like this project distributes solutions in the repository and does not contain any version compatible with k8s 1.22/OCP 4.9. (More info). Following some findings by checking the distributions published:

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 community-operators 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 information and tips see the comment.

camilamacedo86 commented 3 years ago

@liyinan926 @yuchaoran2011

aneagoe commented 3 years ago

It would be really nice to get some traction around this such that we're not blocked when k8s 1.22/OKD 4.9 are out.

camilamacedo86 commented 3 years ago

Hi @aneagoe,

Just to let you know 1.22/OKD 4.9 are out already.

aneagoe commented 3 years ago

@camilamacedo86 k8s 1.22 is out, OCP 4.9 is out, OKD 4.9 is not yet stable (according to https://origin-release.apps.ci.l2s4.p1.openshiftapps.com/). Still, would love to see this issue at least assigned and get some attention.

camilamacedo86 commented 3 years ago

Hi @aneagoe,

But when you publish into community-operators it will be available by default in the OCP catalog as well. So, the OCP users are unable to get your solution on 4.9. See; https://docs.openshift.com/container-platform/4.9/operators/understanding/olm-rh-catalogs.html

sairamankumar2 commented 2 years ago

Hi @aneagoe @camilamacedo86, I would like to work on fix for this issue. Can i start working on PR for a possible fix, if someone else is already not working on the required change?

aneagoe commented 2 years ago

@sairamankumar2 afaik there's no one looking at this. Also, from what I can tell, the version on operatorhub is quite old (2.4) and has not been actively maintained. So perhaps there are two issues at hand here... one for bumping the APIs for the operator itself and another for syncing and updating it on operatorhub.

sairamankumar2 commented 2 years ago

I think the first thing we might be required to do is to upgrade the APIs for the operator as users installing operators on k8s cluster with 1.22 version might face issues.

@liyinan926 Can I take this issue to fix and creating a PR for the same if no other person is working on the API version bump?