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:
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.
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