Bug 1831081 - The OLM "where to install operator" dialog does not clearly indicate what the error condition is [NEEDINFO]
Summary: The OLM "where to install operator" dialog does not clearly indicate what the...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Management Console
Version: 4.5
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ---
: 4.6.0
Assignee: Jakub Hadvig
QA Contact: Yadan Pei
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-05-04 15:29 UTC by Clayton Coleman
Modified: 2020-10-27 15:59 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-27 15:58:53 UTC
Target Upstream Version:
jhadvig: needinfo? (ecordell)


Attachments (Terms of Use)
Screenshot of install error (58.49 KB, image/png)
2020-05-04 15:29 UTC, Clayton Coleman
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github openshift console pull 5964 0 None closed Bug 1831081: Indicate action needed when selected namespace does not support operator's installation mode 2020-12-30 03:36:20 UTC
Red Hat Product Errata RHBA-2020:4196 0 None None None 2020-10-27 15:59:14 UTC

Description Clayton Coleman 2020-05-04 15:29:00 UTC
Created attachment 1684880 [details]
Screenshot of install error

Reproduce

1. Log in as kubeadmin
2. Go to openshift-operators namespace to look at what is installed already
3. Decide to install an operator
4. Go to operator hub
5. Select an openshift optional operator (cluster application migrator)
6. Click install

Expected: able to install correctly without selection
Actual: Received error message that did not convey what to do to fix the problem

The attached image shows the error "Namespace does not support initialization mode" because my current context is "openshift-operators".  However, the message does not tell the user *what to do* in order to successfully install.

Even with all of the knowledge I had as an advanced user of OpenShift, it was unclear what the dialog wanted me to do (which was to create a namespace for this special operator).  However, that's a usability failure because I shouldn't have to make these decisions.

Expected the dialog to automatically suggest a valid namespace (if this was a first party operator), to display a better error message if i did override that choice (to tell me exactly what i needed to do to fix it), and to in general not require users to make decisions with insufficient context.

The better experience would have been to not let me select that namespace in the first place and have a specific openshift-* namespace reserved for CAM (probably on their end). If they weren't a first party operator, it should have given me a suggested namespace name and then allowed me to create inline. If I still overrode that, a better message would have been "The selected namespace cannot be used to install this operator. You must select an empty namespace that is not one of the reserved openshift prefixed namespaces."

Setting to high because we're 4 releases in to OCP 4.x and we're still confusing humans on this page :)  This is a huge usability gap that needs to be closed in order for us to be successful for new users installing optional operators.

Comment 1 Evan Cordell 2020-05-05 15:01:09 UTC
This should be mostly addressed in console, but keeping on OLM for now to help write the messages.

Comment 2 Evan Cordell 2020-05-15 14:25:23 UTC
Suggestions for improving this UX:


If the selected namespace does not support the installmode of the operator, a message with more specifics should be displayed. For example:

"The selected namespace (openshift-operators) configures operators to watch all namespaces, but the selected operator does not support watching all namespaces."

"The selected namespace (elasticsearch) configures operators to watch one namespace (elasticsearch), but the selected operator does not support watching its installation namespace"

In addition, it would be useful to know what installmodes _are_ supported by the operator when there is an error. "Supported installation modes are: AllNamespace, SingleNamespace" - would be great to link to additional docs on these topics so that we can educate users about what they mean.

If the selected namespace is unsupported, we should suggest other namespaces that are supported (query for operatorgroups across all namespaces and show those namespaces as options).


With these options in mind, moving to the console team for further triage. This is not something that can be provided directly by OLM, since these messages are provided before any resources are created on the cluster (unless we'd like to discuss dry-run as a way to get this feedback to the console).

As an aside, this UX is an area of active R&D and will be addressed at a more fundamental level in upcoming releases. Until then, it makes sense to improve the console experience.

Comment 3 Jakub Hadvig 2020-05-21 12:04:37 UTC
>>>
In addition, it would be useful to know what install modes _are_ supported by the operator when there is an error. "Supported installation modes are: AllNamespace, SingleNamespace" - would be great to link to additional docs on these topics so that we can educate users about what they mean.
>>>

Isnt that obvious from the "Installation Mode" section ? Meaning if the "All namespaces on the cluster" radio label is
greyed out the only "Single namespace" installation is available and vice versa.

I could imagine to change the Alert to the mentioned: 
"The selected namespace (elasticsearch) configures operators to watch one namespace (elasticsearch), but the selected operator does not support watching its installation namespace"
... and add the link to docs.

>>>
If the selected namespace is unsupported, we should suggest other namespaces that are supported (query for operatorgroups across all namespaces and show those namespaces as options).

>>>
Do we really wanna show full list of suggested namespaces? Also not sure if I understand correctly, should we make and API call for OperatorGroups across all the namespaces, or 
suggest those namespaces that are in the OperatorGroups that are passed to the OperatorHubSubscribe component by Firehose?

Comment 4 bpeterse 2020-05-26 15:16:00 UTC
We are discussing the best solution for this one, deferring fix for 4.6.

Comment 7 tony.wu 2020-07-07 21:39:37 UTC
Evan mentioned 2 suggestions:
>>>
1. A non-global Operator trying to install in “openshift-operators” Namespace:
“The selected namespace (openshift-operators) configures operators to watch all namespaces, but the selected operator does not support watching all namespaces.”
2. A global Operator trying to install in a Namespace other than “openshift-operators”:
“The selected namespace (elasticsearch) configures operators to watch one namespace (elasticsearch), but the selected operator does not support watching its installation namespace”
>>>

We actually don’t need the 2nd case because UI already blocked this. So we could leave that out and tackle the 1st case.

Comment 8 tony.wu 2020-07-07 21:48:33 UTC
This is how the error box currently look like in the above "1st case":
>>>
Namespace does not support installation mode
The operator group in the openshift-operators namespace does not support the single namespace installation mode.
>>>

Peter from the UXD team will help improve the error message so it's more explicit that users need to choose another Namespace other than "openshift-operators".

Comment 9 Peter Kreuser 2020-07-08 21:37:53 UTC
Operator developers can now specify a suggested namespace via annotation that will be presented in this form (and created if it doesn't yet exist,) so I believe that should lighten the UX load for the user somewhat: http://openshift.github.io/openshift-origin-design/designs/administrator/olm/install-forcenamespace/

If the user did override that or a suggested namespace wasn't specified, the message should be clearer as to why they can't use this particular namespace. I'm not sure how realistic it is to just list out other namespaces that do support this install mode, as the user would probably have a specific one in mind they want to use.

I would suggest updating the error message to be:
"The operator group in the [ns name] namespace does not support the single namespace installation mode. Select a different installation namespace that supports this mode."

Of note is that there are designs being done to allow the user to create their own new namespace (whatever that may be) from this screen, which also may help here, and maybe could be targeted for 4.7: https://docs.google.com/document/d/1XyTNPstMl9-DZWMfc1JKJq-v5uyILQGamdlWqrsAN9c/edit?usp=sharing

Comment 13 Yanping Zhang 2020-07-29 10:20:42 UTC
Checked on OCP 4.6 cluster with payload 4.6.0-0.nightly-2020-07-25-091217
Try to install an operator not support all namespaces mode, choose "openshift-operators" as "Installed Namespace", click "Install", an error info shows up:
Danger alert:Namespace does not support installation mode
The openshift-operators namespace is reserved for global operators that watch all namespaces. To install an operator in a single namespace, select a different namespace where the operand should run.

The bug is fixed.

Comment 15 errata-xmlrpc 2020-10-27 15:58:53 UTC
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 (OpenShift Container Platform 4.6 GA Images), 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/RHBA-2020:4196


Note You need to log in before you can comment on or make changes to this bug.