Bug 2014488
Summary: | Custom operator cannot change orders of condition tables | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | chrzhang |
Component: | Management Console | Assignee: | Jon Jackson <jonjacks> |
Status: | CLOSED ERRATA | QA Contact: | Xiyun Zhao <xiyuzhao> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 4.8 | CC: | aos-bugs, davegord, jdelft, jesusr, jonjacks, tony.wu, xiyuzhao, yapei |
Target Milestone: | --- | ||
Target Release: | 4.10.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
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.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2022-03-10 16:20:08 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: |
Description
chrzhang
2021-10-15 11:44:34 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 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. 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. 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. 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 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 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 |