lib-bucket-provisioner uses outdated CRD versions

[davidkarlsen]

Environment info

• NooBaa Operator Version: noobaa-operator.v5.8.0
• Platform: openshift 4.10

Actual behavior

I get

api-server resource not found installing CustomResourceDefinition objectbucketclaims.objectbucket.io: GroupVersionKind apiextensions.k8s.io/v1beta1, Kind=CustomResourceDefinition not found on the cluster. This API may have been deprecated and removed, see https://kubernetes.io/docs/reference/using-api/deprecation-guide/ for more information.

on the lib-bucket-provisioner which noobaa operator depends on

Expected behavior

1. should install a lib-bucket-provisioner which is updated to use apiextensions.k8s.io/v1

Steps to reproduce

1. install on OCP 4.10

More information - Screenshots / Logs / Other output

[guymguym]

Hi @davidkarlsen I am not sure exactly where you get this error exactly - are you using the noobaa cli to install or using ODF? Where is this error coming from?

I see that the last version the cli used to install the OBC CRD with apiextensions-v1beta1 was in v5.6 - https://github.com/noobaa/noobaa-operator/blob/5.6/deploy/obc/objectbucket.io_objectbucketclaims_crd.yaml#L1

and since v5.7 we already used apiextensions-v1 - https://github.com/noobaa/noobaa-operator/blob/5.7/deploy/obc/objectbucket.io_objectbucketclaims_crd.yaml#L1

but with downstream ODF and OLM the dependency on lib-bucket-provisioner is more complex because it is shared with rook.

[guymguym]

@davidkarlsen Did you take those CRDs directly from lib-bucket-provisioner by any chance? I see that they still host the CRD with apiextensions-v1beta1 here - https://github.com/kube-object-storage/lib-bucket-provisioner/blob/master/deploy/crds/objectbucket_v1alpha1_objectbucket_crd.yaml

[davidkarlsen]

@guymguym I installed from operator hub and OLM.

[guymguym]

@dannyzaken are you aware of such an issue with OCP?

[dannyzaken]

in ODF the OB\OBC CRDs are owned by OCS-operator. The problem here is only in upstream deployments where the CRDs are owned by lib-bucket-provisioner. I see the CRDs there are still v1beta1. once it is fixed, it also requires a new operator hub package. I think that as a workaround, for now, the CRDs can be installed manually.

[guymguym]

@dannyzaken Maybe I'm missing something but isn't it an ODF operator installation? This is installed from operator hub in OCP right? How is this related to upstream lib-bucket-provisioner?

[dannyzaken]

If I understand correctly, this is an installation of upstream noobaa from the operator hub on OCP. @davidkarlsen correct me if I'm wrong.

[davidkarlsen]

If I understand correctly, this is an installation of upstream noobaa from the operator hub on OCP. @davidkarlsen correct me if I'm wrong.

Correct

[kastl-ars]

It looks like I fell into the same trap today, following the installation instructions from operatorhub.

https://artifacthub.io/packages/olm/community-operators/noobaa-operator?modal=install

I get a pending csv due to missing CRDs (requirements not met).

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: my-noobaa-operator
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: operatorgroup
  namespace: my-noobaa-operator
spec:
  targetNamespaces:
  - my-noobaa-operator
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: my-noobaa-operator
  namespace: my-noobaa-operator
spec:
  channel: alpha
  name: noobaa-operator
  source: operatorhubio-catalog
  sourceNamespace: olm
EOF