Creating tracker Bug so that this changes get added in Fass agent +++ This bug was initially created as a clone of Bug #2182041 +++ Description of problem (please be detailed as possible and provide log snippests): When OCS-Operator is installed directly(not as a dependency of ODF Operator), the OCS-Operator pod throws the error "no matches for kind \"NooBaa\" in version \"noobaa.io/v1alpha1\"" This is because OCS-Operator does not install NooBaa CRD Version of all relevant components (if applicable): OCS-Operator v4.12.z Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)? Is there any workaround available to the best of your knowledge? Create a NooBaa CRD manually on the cluster Rate from 1 - 5 the complexity of the scenario you performed that caused this bug (1 - very simple, 5 - very complex)? Can this issue reproducible? Yes Can this issue reproduce from the UI? If this is a regression, please provide more details to justify this: Steps to Reproduce: 1. Create OCS-Operator subscription 2. Check the logs of OCS-Operator pod Actual results: Error is shown in the logs of pod {"level":"error","ts":1679650474.2685232,"logger":"controller-runtime.source","msg":"if kind is a CRD, it should be installed before calling Start","kind":"NooBaa.noobaa.io","error":"no matches for kind \"NooBaa\" in version \"noobaa.io/v1alpha1\"","stacktrace":"sigs.k8s.io/controller-runtime/pkg/source.(*Kind).Start.func1.1\n\t/remote-source/app/vendor/sigs.k8s.io/controller-runtime/pkg/source/source.go:139\nk8s.io/apimachinery/pkg/util/wait.runConditionWithCrashProtectionWithContext\n\t/remote-source/app/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:233\nk8s.io/apimachinery/pkg/util/wait.WaitForWithContext\n\t/remote-source/app/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:660\nk8s.io/apimachinery/pkg/util/wait.poll\n\t/remote-source/app/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:594\nk8s.io/apimachinery/pkg/util/wait.PollImmediateUntilWithContext\n\t/remote-source/app/vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:545\nsigs.k8s.io/controller-runtime/pkg/source.(*Kind).Start.func1\n\t/remot... Expected results: No error should be shown and OCS Operator should reconcile storageCluster Additional info: --- Additional comment from RHEL Program Management on 2023-03-27 11:45:04 UTC --- This bug having no release flag set previously, is now set with release flag 'odf‑4.13.0' to '?', and so is being proposed to be fixed at the ODF 4.13.0 release. Note that the 3 Acks (pm_ack, devel_ack, qa_ack), if any previously set while release flag was missing, have now been reset since the Acks are to be set against a release flag. --- Additional comment from Nitin Goyal on 2023-03-28 08:49:59 UTC --- This is happening because we are adding noobaa into the scheme. We do create Noobaa CRs as part of the reconciliation that's why we need those. So I would say this is working as expected. --- Additional comment from Dhruv Bindra on 2023-03-28 09:05:50 UTC --- Adding the NooBaa package to the scheme won't throw the error. OCS-Operator might be watching for NooBaa CRs so when the cache is built initially it cannot find NooBaa CRD on the cluster and it throws the error. For this kind of scenario, we should only watch the CR if the CRD is present in the cluster. --- Additional comment from Nitin Goyal on 2023-03-28 11:08:29 UTC --- I have some concerns even though I submitted a pull request. If the Operator Lifecycle Manager (OLM) installs the Custom Resource Definition (CRD) of NooBaa after the OCS operator, it could result in us not being able to monitor NooBaa in the product for time being and the workaround would be restarting the OCS operator. --- Additional comment from Nitin Goyal on 2023-03-31 05:10:06 UTC --- (In reply to Nitin Goyal from comment #4) > I have some concerns even though I submitted a pull request. If the Operator > Lifecycle Manager (OLM) installs the Custom Resource Definition (CRD) of > NooBaa after the OCS operator, it could result in us not being able to > monitor NooBaa in the product for time being and the workaround would be > restarting the OCS operator. This is no longer an issue because if we come across the CRD for the first time during reconciliation and it was not present during startup, we will simply restart the pod. --- Additional comment from RHEL Program Management on 2023-04-04 15:39:05 UTC --- This BZ is being approved for ODF 4.13.0 release, upon receipt of the 3 ACKs (PM,Devel,QA) for the release flag 'odf‑4.13.0 --- Additional comment from RHEL Program Management on 2023-04-04 15:39:05 UTC --- Since this bug has been approved for ODF 4.13.0 release, through release flag 'odf-4.13.0+', the Target Release is being set to 'ODF 4.13.0 --- Additional comment from errata-xmlrpc on 2023-04-17 13:27:07 UTC --- This bug has been added to advisory RHBA-2023:108078 by Boris Ranto (branto) --- Additional comment from errata-xmlrpc on 2023-04-17 13:27:10 UTC --- Bug report changed to ON_QA status by Errata System. A QE request has been submitted for advisory RHBA-2023:108078-01 https://errata.devel.redhat.com/advisory/108078 --- Additional comment from Filip Balák on 2023-05-02 09:34:42 UTC --- The issue is not observed with ocs-operator.v4.13.0-164.stable. --> VERIFIED