Bug 1831081
| Summary: | The OLM "where to install operator" dialog does not clearly indicate what the error condition is | ||||||
|---|---|---|---|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Clayton Coleman <ccoleman> | ||||
| Component: | Management Console | Assignee: | Jakub Hadvig <jhadvig> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Yadan Pei <yapei> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 4.5 | CC: | aos-bugs, ecordell, jhadvig, jokerman, pkreuser, tony.wu, yanpzhan | ||||
| Target Milestone: | --- | ||||||
| Target Release: | 4.6.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2020-10-27 15:58:53 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
This should be mostly addressed in console, but keeping on OLM for now to help write the messages. 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. >>> 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? We are discussing the best solution for this one, deferring fix for 4.6. 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. 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". 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 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. 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 The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |
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.