Description of problem (please be detailed as possible and provide log snippests): ------------------------------------------------------------------------ In an OCP 4.3.3 cluster, installed OCS 4.2.1 via UI. It is seen that a new CSV "lib-bucket-provisioner.v1.0.0 " and a corresponding pod is created in the openshift-storage namespace. Not sure if this is as per design or an extra pod created (similar to Bug 1797938) $ oc get csv -n openshift-storage NAME DISPLAY VERSION REPLACES PHASE lib-bucket-provisioner.v1.0.0 lib-bucket-provisioner 1.0.0 Succeeded ocs-operator.v4.2.1 OpenShift Container Storage 4.2.1 Succeeded $ oc get pods -o wide -n openshift-storage|grep bucket lib-bucket-provisioner-dfbf96f75-p2287 1/1 Running 0 10h 10.130.2.11 ip-10-0-60-169.us-east-2.compute.internal <none> <none> The Operator has 2 offerings - OB and OBC. Version of all relevant components (if applicable): ------------------------------------------------------ $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.3.3 True False 28m Cluster version is 4.3.3 OCS version = 4.2.1 Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)? ------------------------------------- No Is there any workaround available to the best of your knowledge? -------------------------- Not sure Rate from 1 - 5 the complexity of the scenario you performed that caused this bug (1 - very simple, 5 - very complex)? ---------------------------------- 2 Can this issue reproducible? ------------------------------ Tested once. Found only in OCP 4.3.3 build + OCS 4.2.1 combination Can this issue reproduce from the UI? --------------------------------- Yes If this is a regression, please provide more details to justify this: ----------------------------------- Maybe some change in OCP build brought this out, but wanted to first confirm if OCS is involved. Steps to Reproduce: ------------------ 1. Create an OCP 4.3.3 LIVE cluster 2. Install OCS 4.2.1 following documentation. 3. Check the lib-bucket-provisioner pod and csv created after Installing OCS subscription(before OCS storage Cluster is created) ========CSV ====== NAME DISPLAY VERSION REPLACES PHASE lib-bucket-provisioner.v1.0.0 lib-bucket-provisioner 1.0.0 Succeeded ocs-operator.v4.2.1 OpenShift Container Storage 4.2.1 Installing -------------- =======PODS ====== NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES lib-bucket-provisioner-dfbf96f75-p2287 1/1 Running 0 34s 10.130.2.11 ip-10-0-60-169.us-east-2.compute.internal <none> <none> noobaa-operator-6dbc556c66-swtzq 1/1 Running 0 22s 10.131.2.10 ip-10-0-81-82.us-east-2.compute.internal <none> <none> ocs-operator-78c89fb795-sz9nq 0/1 Running 0 22s 10.130.2.13 ip-10-0-60-169.us-east-2.compute.internal <none> <none> rook-ceph-operator-6dff58bc99-rs5sh 0/1 ContainerCreating 0 22s <none> ip-10-0-60-169.us-east-2.compute.internal <none> <none> Actual results: --------------------- lib-bucket-provisioner is created in openshift-storage namespace and its usage is unclear Expected results: ----------------- Is this as per design ? Additional info: -------------------- $ oc describe pod lib-bucket-provisioner-dfbf96f75-p2287 -n openshift-storage Name: lib-bucket-provisioner-dfbf96f75-p2287 Namespace: openshift-storage Priority: 0 PriorityClassName: <none> Node: ip-10-0-60-169.us-east-2.compute.internal/10.0.60.169 Start Time: Tue, 25 Feb 2020 22:41:03 +0530 Labels: name=lib-bucket-provisioner pod-template-hash=dfbf96f75 Annotations: alm-examples: [ { "apiVersion": "objectbucket.io/v1alpha1", "kind": "ObjectBucketClaim", "metadata": { "name": "my-obc", "namespace": "my-app" }, "spec": { "storageClassName": "object-bucket-class", "generateBucketName": "my-obc", "additionalConfig": {} }, "status": {} }, { "apiVersion": "objectbucket.io/v1alpha1", "kind": "ObjectBucket", "metadata": { "name": "my-obc" }, "spec": { "storageClassName": "object-bucket-class", "reclaimPolicy": "Delete", "claimRef": { "name": "my-obc", "namespace": "my-app" }, "endpoint": { "bucketHost": "xxx", "bucketPort": 80, "bucketName": "my-obc-1234-5678-1234-5678", "region": "xxx", "subRegion": "xxx", "additionalConfig": {} }, "additionalState": {} }, "status": {} } ] capabilities: Basic Install categories: Storage,Big Data certified: false containerImage: kubernetes/pause createdAt: 2014-07-19T07:02:32.267701596Z description: Library for the dynamic provisioning of object store buckets to be used by object store providers. k8s.v1.cni.cncf.io/networks-status: [{ "name": "openshift-sdn", "interface": "eth0", "ips": [ "10.130.2.11" ], "dns": {}, "default-route": [ "10.130.2.1" ] }] olm.operatorGroup: openshift-storage-cd6rm olm.operatorNamespace: openshift-storage olm.targetNamespaces: openshift-storage openshift.io/scc: restricted repository: https://github.com/kube-object-storage/lib-bucket-provisioner support: Red Hat Status: Running IP: 10.130.2.11 Controlled By: ReplicaSet/lib-bucket-provisioner-dfbf96f75 Containers: lib-bucket-provisioner: Container ID: cri-o://247ae821c4bc7357ba3ff40f724f591ed105ea7953f30cce9462a718df13abd1 Image: kubernetes/pause Image ID: docker.io/kubernetes/pause@sha256:b31bfb4d0213f254d361e0079deaaebefa4f82ba7aa76ef82e90b4935ad5b105 Port: <none> Host Port: <none> State: Running Started: Tue, 25 Feb 2020 22:41:12 +0530 Ready: True Restart Count: 0 Limits: cpu: 1 memory: 128Mi Requests: cpu: 1m memory: 32Mi Environment: WATCH_NAMESPACE: openshift-storage (v1:metadata.namespace) POD_NAME: lib-bucket-provisioner-dfbf96f75-p2287 (v1:metadata.name) OPERATOR_NAME: lib-bucket-provisioner Mounts: /var/run/secrets/kubernetes.io/serviceaccount from lib-bucket-provisioner-token-bxfc4 (ro) Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True Volumes: lib-bucket-provisioner-token-bxfc4: Type: Secret (a volume populated by a Secret) SecretName: lib-bucket-provisioner-token-bxfc4 Optional: false QoS Class: Burstable Node-Selectors: <none> Tolerations: node.kubernetes.io/memory-pressure:NoSchedule node.kubernetes.io/not-ready:NoExecute for 300s node.kubernetes.io/unreachable:NoExecute for 300s Events: <none>
Created attachment 1665807 [details] screenshot from UI
Like the Operator description in the Screenshot says, this is a no-op operator that is used as dependency by other operators (NooBaa in this case) to make use of the CRDs. This is how the dependency model of OLM is and we can't do much about it. https://github.com/openshift/ocs-operator/pull/424 is the PR that makes OCS own these CRDs, thus removing this problem with dependency resolution.
*** This bug has been marked as a duplicate of bug 1798571 ***