Bug 2011038 - optional operator conditions are confusing
Summary: optional operator conditions are confusing
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Management Console
Version: 4.8
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: 4.10.0
Assignee: Joe Caiani
QA Contact: Xiyun Zhao
URL:
Whiteboard:
Depends On:
Blocks: 2021702
TreeView+ depends on / blocked
 
Reported: 2021-10-05 19:45 UTC by Michael Hrivnak
Modified: 2022-03-10 16:17 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-03-10 16:17:19 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
screenshot (100.34 KB, image/png)
2021-10-05 19:45 UTC, Michael Hrivnak
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github openshift console pull 10388 0 None open Bug 2011038: Render correct conditions for csv vs installplan and subscriptioncondition 2021-11-02 21:41:09 UTC
Red Hat Product Errata RHSA-2022:0056 0 None None None 2022-03-10 16:17:44 UTC

Description Michael Hrivnak 2021-10-05 19:45:20 UTC
Created attachment 1829622 [details]
screenshot

Description of problem:

I installed a partner operator in a 4.8.12 cluster. Looking at the installed operator status page here: https://console-openshift-console.apps.demo.ocp.home/k8s/ns/openshift-operators/operators.coreos.com~v1alpha1~ClusterServiceVersion/blackduck-connector-operator.v1.0.0/

... the "Conditions" at the bottom are confusing, and I don't think it's just this particular operator that's the issue. Screenshot attached.

The ClusterServiceVersion conditions do not have a field called "Status". So when the console shows that every listed condition has a "Status" of "True", that is confusing, and I'm not sure where it's getting or deriving that information.

It's also easy to interpret this table as saying the operator is in all of these conditions at the same time. Based on some quick slack feedback, it seems there might be an expectation that only the most recent condition represents current state. And the entries are expected to be chronological, so the last one is most recent. It would help to figure out what OLM's intent is here and better represent which entries are historical vs. which represent current state.

This may be related to the CSV taking a different approach to conditions than what's in the k8s API conventions doc: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties

The table shown in the UI would probably work fine for conditions created with that approach. But since OLM is taking a different approach with CSVs, it would help a lot to coordinate and provide some sort of hints or visual guidance about what's the current state vs. not. And getting rid of the "Status" column almost certainly makes sense.

Version-Release number of selected component (if applicable):

4.8.12


How reproducible:

always

Steps to Reproduce:
1. install an optional operator (I used Black Duck in this case)
2. Look at its conditions in the console

Actual results:

screenshot attached

Expected results:

Something that makes it clear what the current status is vs what's historical. Also not having the extra "Status" column that isn't in the source data.


Additional info:

Here is the YAML representation of what's in the screenshot:

  conditions:
    - lastTransitionTime: '2021-10-05T16:54:58Z'
      lastUpdateTime: '2021-10-05T16:54:58Z'
      message: requirements not yet checked
      phase: Pending
      reason: RequirementsUnknown
    - lastTransitionTime: '2021-10-05T16:54:58Z'
      lastUpdateTime: '2021-10-05T16:54:58Z'
      message: 'all requirements found, attempting install'
      phase: InstallReady
      reason: AllRequirementsMet
    - lastTransitionTime: '2021-10-05T16:54:58Z'
      lastUpdateTime: '2021-10-05T16:54:58Z'
      message: waiting for install components to report healthy
      phase: Installing
      reason: InstallSucceeded
    - lastTransitionTime: '2021-10-05T16:54:58Z'
      lastUpdateTime: '2021-10-05T16:54:58Z'
      message: >-
        installing: waiting for deployment
        blackduck-connector-operator-controller-manager to become ready:
        deployment "blackduck-connector-operator-controller-manager" not
        available: Deployment does not have minimum availability.
      phase: Installing
      reason: InstallWaiting
    - lastTransitionTime: '2021-10-05T16:55:17Z'
      lastUpdateTime: '2021-10-05T16:55:17Z'
      message: install strategy completed with no errors
      phase: Succeeded
      reason: InstallSucceeded

Comment 1 Jakub Hadvig 2021-10-07 08:46:22 UTC
Hey Michael, thanks for reporting issue.
Today the installed operator status page is showing the conditions by design, meaning that we are not doing any assumptions and just render the conditions in the given order.
What you are proposing seems valid but it would require also design work. For that reason I would suggest rather to create a RFE in Console's JIRA: 
https://issues.redhat.com/projects/CONSOLE/issue

Sam is this something we would wanna threat as BZ for backport purposes?

Comment 2 Samuel Padgett 2021-10-07 16:56:54 UTC
I think it's reasonable to align the table with the API on the CSV page as a bug fix (i.e. remove columns like `Status` that aren't in the YAML). Larger changes like differentiating between current and historical conditions require design input and probably should be a story.

Comment 3 Jakub Hadvig 2021-10-11 06:38:35 UTC
@Joe I would check the API for the CSV, InstallPlan and Subscription condition types and based on the type I would render appropriate table.

Comment 6 Joe Caiani 2021-11-16 16:31:18 UTC
@xiyuzhao it looks like this bugzilla must be manually set to verified. could you look into this when you get a chance? Thanks!

Comment 7 Xiyun Zhao 2021-11-18 07:02:57 UTC
This bug has been verified and fixed on payload 4.10.0-0.nightly-2021-11-15-034648

Verification Steps:
1. Log in OCP, and install an optional operator (Here I used PackageServer, and installed 'Advanced Cluster Management for Kubernetes' for testing)
2. Navigate to the Operator Details page
3. Verify if the column of Conditions is clearer than before and also does not have the extra "Status" column that isn't in the source data. 

Result:
3. The columns 'Phase' is instead of the old two which include 'Type, Status' to make the condition much clearer than before. 
   Now the Conditions table is updated to handle the types: clusterserviceversion, installplan, and subscription conditions as called out in the request

Comment 11 errata-xmlrpc 2022-03-10 16:17:19 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 (Moderate: OpenShift Container Platform 4.10.3 security update), 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/RHSA-2022:0056


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