Description of problem: For multiple resources that are managed by HCO, on updating them (e.g. add a label), they get reconciled and actual resource shows correct labels and metadata.resourceversion gets updated. However, HCO.status.relatedObjects continues to show the old resourceVersion associated with that resource Version-Release number of selected component (if applicable): CNV: 4.9.0-230 [cnv-qe-jenkins@iuo-tier2-49-rlqdh-executor ~]$ oc version Client Version: 4.9.0-202109101042.p0.git.96e95ce.assembly.stream-96e95ce Server Version: 4.9.0-rc.4 Kubernetes Version: v1.22.0-rc.0+af080cb [cnv-qe-jenkins@iuo-tier2-49-rlqdh-executor ~]$ =========== How reproducible: Consistently for the followings: Kind: PriorityClass, Name: kubevirt-cluster-critical Kind: KubeVirt, name: kubevirt-kubevirt-hyperconverged Kind: CDI, name: cdi-kubevirt-hyperconverged Kind: ConfigMap, name: kubevirt-storage-class-defaults Kind: Role, name: hco.kubevirt.io:config-reader Kind: RoleBinding, name: hco.kubevirt.io:config-reader Kind: NetworkAddonsConfig, name: cluster Kind: VMImportConfig, name: vmimport-kubevirt-hyperconverged Kind: ConfigMap, name: v2v-vmware Kind: ServiceMonitor, name: kubevirt-hyperconverged-operator-metrics Kind: Route, name: hyperconverged-cluster-cli-download Kind: Service, name: hyperconverged-cluster-cli-download Kind: ConsoleQuickStart, name: connect-ext-net-to-vm Kind: ConsoleQuickStart, name: create-win10-vm Kind: ConsoleQuickStart, name: create-rhel-vm Kind: ConsoleQuickStart, name: import-vmware-vm Kind: ConfigMap, name: grafana-dashboard-kubevirt-top-consumers Steps to Reproduce: 1. For any resource using kubectl edit command add a label and save the same 2. Wait for the label to disappear from kubectl get command (happens within seconds) 3. Validate metadata.resourceVersion of the resource has been updated 4. Check hco.status.relatedObject still points to older resource version value of the managed resource. Actual results: hco.status.relatedObject still points to older resource version value of the reconciled managed resource. Expected results: hco.status.relatedObject should display correct resourceVersion of a reconciled resource. Additional info:
A quick question: Which one is correct? Option 1) The resource version of an object in relatedObjects must be the latest resource version that is applied by HCO Option 2) The resource version of an object in relatedObjects must be the latest resource version that is observed by HCO If Option 1 -> I found that we don't update status of HCO when reconcilation is not triggered by HCO. This PR fixes that issue https://github.com/kubevirt/hyperconverged-cluster-operator/pull/1558 If Option 2 -> I think it doesn't make sense. We should state what we applied. Also, to be able to implement it, we should reconcile HCO's status for every status change on secondary CRs even when the changes are unrelated to HCO, which seems waste to me. @stirabos @nunnatsa Could you please confirm that we want Option 1.
https://github.com/openshift/custom-resource-status/blob/master/objectreferences/README.md is not that clear on this, but yes I think that option 1 should be enough.
Update: Debarati found that hco-operator doesn't update status part for PriorityClass object. I am fixing it with this PR: https://github.com/kubevirt/hyperconverged-cluster-operator/pull/1565
Verified against 4.10.0-221 All resources that are managed by HCO (showing up under hco.status.relatedObjects are now getting reconciled. This has been validated by: 1) updating individual resources - add a label to metadata.label 2) watch it getting overritten 3) resource version of the object is updated 4) updated resource version is seen by hco (hco.status.relatedObjects reflects that)
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 Virtualization 4.10.0 Images security and bug fix 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:0947