Description of problem: While it is documented in our installation documentation to only deploy CNV using the openshift-cnv namespace, nothing prevent someone of deploying in the openshift-operators namespace and get a failed deployment. The openshift-operators is also the default namespace for many other operators and someone familiar with deployment might use this namespace out of habit. Version-Release number of selected component (if applicable): All CNV 2.x version How reproducible: Everytime you deploy in other namespace than openshift-cnv. Steps to Reproduce: 1. Deploy CNV in the openshift-operators namespace 2. Deployment fail with unknown errors while still trying to deploy 3. Actual results: The deployment start in the openshift-operators namespace Expected results: The deployment does not start and the user receive an error message to not deploy in this namespace. Additional info:
Oren, I believe that you https://github.com/kubevirt/hyperconverged-cluster-operator/pull/408 should address this problem, right?
(In reply to Dan Kenigsberg from comment #5) > Oren, I believe that you > https://github.com/kubevirt/hyperconverged-cluster-operator/pull/408 should > address this problem, right? Correct, I'm in contact with OLM to try to understand the error I got when trying to configure the operator's InstallMode to be supported only at one namespace. Expected result is greying-out the default option (which installs the operator in openshift-operators namespaces and copies it to all namespaces). https://github.com/operator-framework/operator-lifecycle-manager/issues/1297
InstallMode of "AllNamespaces" and "MultipleNamespaces" have been changed to false in CSV, and the PR has been merged and cherry-picked to release-2.3 Master - https://github.com/kubevirt/hyperconverged-cluster-operator/pull/461/ 2.3 Branch - https://github.com/kubevirt/hyperconverged-cluster-operator/pull/467 This should grey-out the default option in operator subscription UI page of OLM. Another ongoing PR is intending to validate the namespace of deployed HCO CR, to be compatible with the convention (U/S: kubevirt-hyperconverged; D/S: openshift-cnv). https://github.com/kubevirt/hyperconverged-cluster-operator/pull/483
Changing to "ON_QA" as downstream bundle image with this change will be consumable shortly. To summarize, we implemented 3 different fail-safe methods: 1. User cannot deploy the operator in default option where it would be installed on all namespaces - this option is greyed-out. 2. Suggested namespace encourages the user to deploy at a specific namespace. If the user chooses another one, the HCO operator installation fails and hco-operator pod crashloops with log of: "Please re-deploy this operator into kubevirt-hyperconverged namespace”,”Expected.Namespace”:”kubevirt-hyperconverged”,”Deployed.Namespace”:”default”,”error”:”Operator running in different namespace than expected” 3. When the user tries to deploy the HCO CR at the wrong namespace, he gets a validation error and the correct namespace is specified.
Created attachment 1669947 [details] verification - grayed out
Created attachment 1669948 [details] verification - time out on install to wrong ns
Created attachment 1669949 [details] verification - error on wrong named cr
Created attachment 1669950 [details] verification logs - error on install to non existing ns
Created attachment 1669951 [details] verification - error on cr create in wrong ns
All three bullets of comment #9 verified. See the screenshots attached. Also, see verified jira cards: CNV-3620, CNV-3940, CNV-4138, CNV-4131 and CNV-3784
The corresponding doc changes are tracked here: https://github.com/openshift/openshift-docs/pull/20118
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2020:2011