Description of problem: IBM is reporting that in the change from 4.4.9=>4.4.10, the OLM does not follow singleNamespace install strategy, but subsequent attempts at installing the operator elsewhere in the cluster (as another singleNamespace install) will see the clusterrole for the previous installation reassigned to the new namespace: they are seeing this for the IBM appConnect operator; there are clear instructions for choosing the install strategy in the documentation and IBM is reporting that the new version of OCP is showing the issue Version-Release number of selected component (if applicable): 4.4.10 How reproducible: unsure as access to the operator can be tricky; there is no cost, but IBMcloud ID is required Steps to Reproduce: 1. install OCP 4.4.10 2. follow IBM docs to install operator: https://www.ibm.com/support/knowledgecenter/SSTTDS_11.0.0/com.ibm.ace.icp.doc/certc_install_appconnoperator.html 3. Actual results: any singleNamespace install of the operator will override the previous install of the same Expected results: operator singleNamespace install strategy will succeed Additional info:
There are must-gathers in the ticket: the direct hydraURLs are: https://access.redhat.com/hydra/rest/cases/02710568/attachments/de7f3c29-00fb-47c0-97f9-c5ac52855811?usePresignedUrl=true https://access.redhat.com/hydra/rest/cases/02710568/attachments/5f9ddaf0-cb0b-4c33-8ac5-8fed290a945a?usePresignedUrl=true if you would prefer to test using RH operators, i would suggest doing so by installing the operators using the singleNamespace strategies: https://docs.openshift.com/container-platform/4.4/operators/understanding_olm/olm-understanding-operatorgroups.html The operator is the IBM appConnect operator; the namespaces involved are 103-testing and do-not-delete cu submitted descriptions of the CSVs and the subs (but not the operatorGroup); please let me know if anything further is needed.
I suspect this is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1855088. I'm going to attempt to reproduce on 4.6, where a fix has already merged.
I was able to install duplicate single-namespace installmode operators -- in this case apicuritooperator.v7.7.0 -- on OCP 4.5.4 and verified that this behavior is fixed there. I'm pretty convinced this is a duplicate at this point. A fix PR is up for the 4.4 backport of the primary bug. *** This bug has been marked as a duplicate of bug 1855088 ***