+++ This bug was initially created as a clone of Bug #1845031 +++ Description of problem: When user procieeds installation steps for CNV Operator from 2.4 channel, the namespace openshift-cnv is not created automatically. When namespace openshift-cnv is created before the installation, it isn't used when user navigates to the OperatorHub from a different namespace (for example, openshift-cnv ns is created with CLI, user is currently in Default namespace in the UI and navigates to Operator Hub to install CNV Operator). Instead, the last active namespace is used (In the previous example, it would be Default). Version-Release number of selected component (if applicable): 4.5.0-rc.1 CNV-2.4 How reproducible: 100% Steps to Reproduce: a) 1. Make sure openshift-cnv namespace doesn't exist 2. Navigate to OperatorHub, search container-native, click install, select 2.4 channel, click install b) 1) Create openshift-cnv namespace 2) Switch to 'Default' project 3) Navigate to OperatorHub, search container-native, click install, select 2.4 channel, click install Actual results: the Openshift Virtualization operator is deployed to the last active namespace, not openshift-cnv Expected results: a) openshift-cnv namespace should be created for the user b) when openshift-cnv namespace exists, it should be used instead of the least recently used namespace it shouldn't matter from which namespace the user navigates to the operatorHub Additional info: --- Additional comment from stirabos on 2020-06-08 10:44:47 UTC --- `operatorframework.io/suggested-namespace: openshift-cnv` is still in the CSV, maybe a regression on OLM console. --- Additional comment from ocohen on 2020-06-08 15:55:13 UTC --- @Radim, same happens if you install CNV 2.3 channel on your same OCP 4.5 cluster? --- Additional comment from rhrazdil on 2020-06-08 19:43:38 UTC --- Hello Oren, yes it happens for CNV 2.3 as well. Í believe I found where the problem lays. When I leave the radio button for the channel selection with its defaulf value, the openshift-cnv namespcae is correctly created and if exists, it is correctly used. However, when I change the channel (2.3 -> 2.x), the behaviour is as stated in the BZ Description. Seems very much like a UI bug. I'm moving this to OCP Management Console
Waiting bug bug to be verified. Adding UpcomingSprint to have it reevaluated in the next cycle.
*** This bug has been marked as a duplicate of bug 1845602 ***