Cause: Front-end OLM descriptor handling only uses the first x-descriptor to render a property on an operand details page.
Consequence: If multiple x-descriptors are defined for a property and the first one in the list is invalid or unsupported it would not render as expected even if a valid and supported x-descriptor was defined further down the list.
Fix: Update our descriptor validation logic to prioritize supported x-descriptors over unsupported ones.
Result: Descriptor-decorated properties will be rendered on the operand details page using the first valid and supported x-descriptor found in the list.
Created attachment 1794268[details]
operand details page 4.8
Description of problem:
when some fields value is None, we didn't display an edit option to change them on operand details page
Version-Release number of selected component (if applicable):
4.8.0-0.nightly-2021-06-24-101028
How reproducible:
Always
Steps to Reproduce:
1. Install 'Argo CD' operator and create 'Argo CD' operand using default YAML or default form
2. Check 'Argo CD' operand details page
3.
Actual results:
2. some fields Controller.Resource Requirement and Grafana.Size, we didn't set value for them, the specDescriptors are:
- description: >-
The limits and requests requirements for the Argo CD Application
Controller container.
displayName: Resource Requirements
path: controller.resources
x-descriptors:
- 'urn:alm:descriptor:com.tectonic.ui:fieldGroup:Controller'
- 'urn:alm:descriptor:com.tectonic.ui:resourceRequirements'
- description: The replica count for the Grafana Deployment.
displayName: Size
path: grafana.size
x-descriptors:
- 'urn:alm:descriptor:com.tectonic.ui:fieldGroup:Grafana'
- 'urn:alm:descriptor:com.tectonic.ui:podCount'
On operand details page, we didn't render Resource Requirement edit modal and Pod count edit option
Expected results:
2. Although these fields have None value, we should still render with correct format then user can edit on operand details page like what we did in OCP 4.6
Additional info:
1. Install Prometheus Operator 0.47.0, then create Prometheus instance with default YAML
2. Check Prometheus operand details, on operand details page, Resource Requirement edit modal is shown although Resource Requirement has all None values
Pod count edit option is also shown correctly so that user can edit the pod count
Verified on 4.9.0-0.nightly-2021-08-16-154237
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.9.0 bug fix and 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-2021:3759
Created attachment 1794268 [details] operand details page 4.8 Description of problem: when some fields value is None, we didn't display an edit option to change them on operand details page Version-Release number of selected component (if applicable): 4.8.0-0.nightly-2021-06-24-101028 How reproducible: Always Steps to Reproduce: 1. Install 'Argo CD' operator and create 'Argo CD' operand using default YAML or default form 2. Check 'Argo CD' operand details page 3. Actual results: 2. some fields Controller.Resource Requirement and Grafana.Size, we didn't set value for them, the specDescriptors are: - description: >- The limits and requests requirements for the Argo CD Application Controller container. displayName: Resource Requirements path: controller.resources x-descriptors: - 'urn:alm:descriptor:com.tectonic.ui:fieldGroup:Controller' - 'urn:alm:descriptor:com.tectonic.ui:resourceRequirements' - description: The replica count for the Grafana Deployment. displayName: Size path: grafana.size x-descriptors: - 'urn:alm:descriptor:com.tectonic.ui:fieldGroup:Grafana' - 'urn:alm:descriptor:com.tectonic.ui:podCount' On operand details page, we didn't render Resource Requirement edit modal and Pod count edit option Expected results: 2. Although these fields have None value, we should still render with correct format then user can edit on operand details page like what we did in OCP 4.6 Additional info: