Bug 2014488 - Custom operator cannot change orders of condition tables
Summary: Custom operator cannot change orders of condition tables
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: Jon Jackson
QA Contact: Xiyun Zhao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-10-15 11:44 UTC by chrzhang
Modified: 2022-09-20 09:55 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: On the operaand details page, we created a special case where the conditions table for the status.conditions property was always rendered before all other conditions tables. Consequence: The status.conditions table did not follow the ordering rules of descriptors, causing unexpected behavior when users tried to change the order of conditions tables. Fix: Remove the special case for status.condtions and only default to rendering it first if no descriptor is defined for that property Result: The table for status.conditions is rendered according to descriptor ordering rules when a descritptor is defined on that property.
Clone Of:
Environment:
Last Closed: 2022-03-10 16:20:08 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift console pull 10364 0 None open Bug 2014488: Fix operand details page conditions table sort order 2021-10-29 14:28:32 UTC
Red Hat Product Errata RHSA-2022:0056 0 None None None 2022-03-10 16:20:25 UTC

Description chrzhang 2021-10-15 11:44:34 UTC
Description of problem:

The IBM developer complains that cannot modify the webUI order for operator condition tables. 

The doc they follow is below:
https://sdk.operatorframework.io/docs/building-operators/golang/references/markers/

They tried following changes while defining the conditions with specific order in it in the types file of the operator:

// ApplicationsStatus Status of the ELM applications
// +operator-sdk:csv:customresourcedefinitions:type=status,order=90
ApplicationsStatus ApplicationsDetails `json:"applicationsStatus,omitempty"`

// Status of the ELM Instance Deployment created and managed by it
// +operator-sdk:csv:customresourcedefinitions:type=status,order=91
DeploymentStatus DeploymentDetails `json:"deploymentStatus,omitempty"`

// Status of the ELM Instance Upgrade
// +operator-sdk:csv:customresourcedefinitions:type=status,order=92
UpgradeStatus UpgradeDetails `json:"upgradeStatus,omitempty"`


However the above order is not working, the order is random for conditions on UI. This "Order" property works for specs attributes.

They think it possible be a bug and also wonder if they is way to setup conditions in a specific order. 



Actual results:

The operator condition WebUI randomly layout

Expected results:

The conditions can setup in order as they wish.

Additional info:

Comment 3 tony.wu 2021-10-19 15:05:10 UTC
I noticed it's been back-n-force on the Red Hat Customer Portal with customer for quite a while. To speed this up a bit, can you get the CSV file from the customer so we can troubleshoot this with the OCP console team? thanks

Comment 4 Varsha 2021-10-19 15:42:13 UTC
Had a look at this issue. I tested the ordering of spec fields in the csv with `operator-sdk` markers.

Example Reference: 
markers defined in `_types.go`: https://github.com/varshaprasad96/memcached-operator/blob/a38fe82c61526fcde6b68127b92aeaf3d5ced241/api/v1alpha1/memcached_types.go#L32-L36

respective ordering in csv: https://github.com/varshaprasad96/memcached-operator/blob/a38fe82c61526fcde6b68127b92aeaf3d5ced241/bundle/manifests/memcached-operator.clusterserviceversion.yaml#L32-L38

It seems to work fine. It would be helpful to check the CSV if the ordering specified with the markers, is the one which appears in the `specDescriptors` array. If so, then it could be that something is wrong with rendering in console.

Comment 5 Varsha 2021-10-19 15:42:41 UTC
Had a look at this issue. I tested the ordering of spec fields in the csv with `operator-sdk` markers.

Example Reference: 
markers defined in `_types.go`: https://github.com/varshaprasad96/memcached-operator/blob/a38fe82c61526fcde6b68127b92aeaf3d5ced241/api/v1alpha1/memcached_types.go#L32-L36

respective ordering in csv: https://github.com/varshaprasad96/memcached-operator/blob/a38fe82c61526fcde6b68127b92aeaf3d5ced241/bundle/manifests/memcached-operator.clusterserviceversion.yaml#L32-L38

It seems to work fine. It would be helpful to check the CSV if the ordering specified with the markers, is the one which appears in the `specDescriptors` array. If so, then it could be that something is wrong with rendering in console.

Comment 6 Jon Jackson 2021-10-25 17:07:33 UTC
Reassigning to myself. Tony @tony.wu and I have discussed this and determined that this is caused by a special case we implemented in the UI. We currently force status.conditions to be rendered above any other conditions tables, regardless of the CSV descriptors. Will update the sort order of the status.conditions table to follow these rules:

- If no descriptor is defined on the status.conditions property, it will be rendered as the first condtions table.
- If a descriptor is defined on the status.conditions property, it will be rendered in the order it appears in the CSV descriptors array.

Comment 13 Xiyun Zhao 2022-01-26 07:43:47 UTC
Thanks for your reply, understanding now

This PR has been retested and verified on payload 4.10.0-0.nightly-2022-01-25-023600

Verification step
1. Login OCP as administrator, create the resource that needed by following Comment9
2. Navigate to the Operators > Installed Operators page, and make sure the "default" project is selected
3. Navigate to Mock Operator -> Mock Resource tab on the Mock Operator CSV details page
4. Navigate to the operand details page
5. Verify if the details page is follow the rule that "If a descriptor is defined on the status.conditions property, it will be rendered in the order it appears in the CSV descriptors array". The three condition will follow below order:
    - Custom Conditions
    - Conditions
    - Other Custom Conditions
6. Go back to  Mock Operator -> YAML tab on the Mock Operator details page. Update the spec.customeresourcedefinitions.statusDescriptors part as below shown. Make sure not x-descriptors is defined for Conditions
statusDescriptors:
          - displayName: Custom Conditions
            path: customConditions
            x-descriptors:
              - 'urn:alm:descriptor:io.kubernetes.conditions'
          - displayName: Conditions
            path: conditions
          - displayName: Other Custom Conditions
            path: otherCustomConditions
            x-descriptors:
              - 'urn:alm:descriptor:io.kubernetes.conditions'
7. Navigate to the operand details page again, verify if the three condition is following the rule "If not x-descriptor is defined on the status.conditions property, it will be rendered as the first conditions table" and shown as below order: 
   - Conditions
    - Custom Conditions
    - Other Custom Conditions
8. Repeat Step 6, make sure the Conditions is removed from the statusDescriptors, and as below shown:
     statusDescriptors:
            - displayName: Other Custom Conditions
            path: otherCustomConditions
            x-descriptors:
              - 'urn:alm:descriptor:io.kubernetes.conditions'
          - displayName: Custom Conditions
            path: customConditions
            x-descriptors:
              - 'urn:alm:descriptor:io.kubernetes.conditions'
9. Navigate to the operand details page again, verify if the three condition is following the rule "If no default status.conditions property is being set, it will be rendered as the first conditions table, and then follow the defined order by customer" and shown as below order: 
    - Conditions
    - Other Custom Conditions
    - Custom Conditions

Result:
5. As the order that defined on CSV file is as below shown:
         statusDescriptors:
          - displayName: Custom Conditions
            path: customConditions
            x-descriptors:
              - 'urn:alm:descriptor:io.kubernetes.conditions'
          - displayName: Conditions
            path: conditions
            x-descriptors:
              - 'urn:alm:descriptor:io.kubernetes.conditions'
          - displayName: Other Custom Conditions
            path: otherCustomConditions
            x-descriptors:
              - 'urn:alm:descriptor:io.kubernetes.conditions'
    The order on the page is as same as defined
        - Custom Conditions
        - Conditions
        - Other Custom Conditions
7. The order on the page is as same as defined
    - Conditions
    - Custom Conditions
    - Other Custom Conditions
9. The order on the page is as same as defined
    - Conditions
    - Other Custom Conditions
    - Custom Conditions

Comment 16 errata-xmlrpc 2022-03-10 16:20:08 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

Comment 17 Xiyun Zhao 2022-06-01 06:22:29 UTC
Correct the last response on Comment 13 for step 7 and Result 7 
7. Navigate to the operand details page again, verify if the three conditions are following the rule "If not x-descriptor is defined on the status.conditions property, it will be rendered as the first conditions table"  
      statusDescriptors:
          - displayName: Other Custom Conditions
            path: customConditions
          - displayName: Conditions
            path: conditions
          - displayName: Custom Conditions
            path: otherCustomConditions
            x-descriptors:
              - 'urn:alm:descriptor:io.kubernetes.conditions'

Result:The order on the page will shown as below
    - Conditions
    - Custom Conditions


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