OCPBUGS-58880,OCPBUGS-56805: fix: clusteroperator: do not update status.relatedobjects if only order changed

[damdo]

RelatedObjects is a slice of []configv1.ObjectReference the equality.Semantic.DeepEqual() here considers different the ordering on the slice and forces a status update on the ClusterOperator object

Especially considering that the slice is built from looping over a r.Scheme().AllKnownTypes() which is a map

This PR orders the two RelatedObjects sources before the DeepEqual() check, to make sure slices with the same elements in different order, are considered equal, avoiding the update loop.

• commit 1: implements the fix
• commit 2: reworks the SyncStatus() to sync the entire status and not only conditions

[openshift-ci-robot]

@damdo: This pull request references Jira Issue OCPBUGS-58880, which is invalid:

• expected the bug to target the "4.20.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

Details

In response to this:

RelatedObjects is a slice of []configv1.ObjectReference the equality.Semantic.DeepEqual() here considers different the ordering on the slice and forces a status update on the ClusterOperator object

Especially considering that the slice is built from looping over a r.Scheme().AllKnownTypes() which is a map

This PR orders the two RelatedObjects sources before the DeepEqual() check, to make sure slices with the same elements in different order, are considered equal, avoiding the update loop.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[damdo]

/assign @sdodson

[sdodson]

/label approved
/jira refresh

[openshift-ci-robot]

@sdodson: This pull request references Jira Issue OCPBUGS-58880, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.20.0) matches configured target version for branch (4.20.0)
• bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @sunzhaohua2

Details

In response to this:

/label approved
/jira refresh

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[sdodson]

/test unit

[damdo]

/cherry-pick release-4.19

[openshift-cherrypick-robot]

@damdo: once the present PR merges, I will cherry-pick it on top of release-4.19 in a new PR and assign it to you.

Details

In response to this:

/cherry-pick release-4.19

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[damdo]

/retest

[damdo]

/hold

For more testing

[openshift-ci-robot]

@damdo: This pull request references Jira Issue OCPBUGS-58880, which is valid.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.20.0) matches configured target version for branch (4.20.0)
• bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @sunzhaohua2

Details

In response to this:

RelatedObjects is a slice of []configv1.ObjectReference the equality.Semantic.DeepEqual() here considers different the ordering on the slice and forces a status update on the ClusterOperator object

Especially considering that the slice is built from looping over a r.Scheme().AllKnownTypes() which is a map

This PR orders the two RelatedObjects sources before the DeepEqual() check, to make sure slices with the same elements in different order, are considered equal, avoiding the update loop.

• commit 1: implements the fix
• commit 2: reworks the SyncStatus() to sync the entire status and not only conditions

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[damdo]

/retest-required

[openshift-ci-robot]

@damdo: This pull request references Jira Issue OCPBUGS-58880, which is valid.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.20.0) matches configured target version for branch (4.20.0)
• bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @sunzhaohua2

The bug has been updated to refer to the pull request using the external bug tracker.

This pull request references Jira Issue OCPBUGS-56805, which is valid.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.20.0) matches configured target version for branch (4.20.0)
• bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @sunzhaohua2

The bug has been updated to refer to the pull request using the external bug tracker.

Details

In response to this:

RelatedObjects is a slice of []configv1.ObjectReference the equality.Semantic.DeepEqual() here considers different the ordering on the slice and forces a status update on the ClusterOperator object

Especially considering that the slice is built from looping over a r.Scheme().AllKnownTypes() which is a map

This PR orders the two RelatedObjects sources before the DeepEqual() check, to make sure slices with the same elements in different order, are considered equal, avoiding the update loop.

• commit 1: implements the fix
• commit 2: reworks the SyncStatus() to sync the entire status and not only conditions

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[damdo]

/assign @nrb

/retest-required

[nrb]

/lgtm
/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: nrb

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [nrb]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[sunzhaohua2]

/label qe-approved

no errors in cluser-capi-operator logs

$ oc -n openshift-cluster-api logs -f cluster-capi-operator-57c8b655b6-8vqzn | grep "Reconciler error" | grep "clusteroperator"                                                    
Defaulted container "cluster-capi-operator" out of: cluster-capi-operator, machine-api-migration
^C

[openshift-ci-robot]

@damdo: This pull request references Jira Issue OCPBUGS-58880, which is valid.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.20.0) matches configured target version for branch (4.20.0)
• bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @sunzhaohua2

This pull request references Jira Issue OCPBUGS-56805, which is valid.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.20.0) matches configured target version for branch (4.20.0)
• bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @sunzhaohua2

Details

In response to this:

RelatedObjects is a slice of []configv1.ObjectReference the equality.Semantic.DeepEqual() here considers different the ordering on the slice and forces a status update on the ClusterOperator object

Especially considering that the slice is built from looping over a r.Scheme().AllKnownTypes() which is a map

This PR orders the two RelatedObjects sources before the DeepEqual() check, to make sure slices with the same elements in different order, are considered equal, avoiding the update loop.

• commit 1: implements the fix
• commit 2: reworks the SyncStatus() to sync the entire status and not only conditions

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[sunzhaohua2]

/unhold

[openshift-ci-robot]

/retest-required

Remaining retests: 0 against base HEAD 694626d and 2 for PR HEAD ea231d3 in total

[openshift-ci]

@damdo: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/okd-scos-e2e-aws-ovn	ea231d3	link	false	/test okd-scos-e2e-aws-ovn

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[damdo]

Openstack failure is unrelated as the issue has been present in that test for a while now (see). I'll talk to shift stack about it

/override ci/prow/e2e-openstack-ovn-techpreview

[openshift-ci]

@damdo: Overrode contexts on behalf of damdo: ci/prow/e2e-openstack-ovn-techpreview

Details

In response to this:

Openstack failure is unrelated as the issue has been present in that test for a while now (see). I'll talk to shift stack about it

/override ci/prow/e2e-openstack-ovn-techpreview

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[openshift-ci-robot]

@damdo: Jira Issue OCPBUGS-58880: All pull requests linked via external trackers have merged:

• openshift/cluster-capi-operator#331

Jira Issue OCPBUGS-58880 has been moved to the MODIFIED state.

Jira Issue OCPBUGS-56805: All pull requests linked via external trackers have merged:

• openshift/cluster-capi-operator#331

Jira Issue OCPBUGS-56805 has been moved to the MODIFIED state.

Details

In response to this:

RelatedObjects is a slice of []configv1.ObjectReference the equality.Semantic.DeepEqual() here considers different the ordering on the slice and forces a status update on the ClusterOperator object

Especially considering that the slice is built from looping over a r.Scheme().AllKnownTypes() which is a map

This PR orders the two RelatedObjects sources before the DeepEqual() check, to make sure slices with the same elements in different order, are considered equal, avoiding the update loop.

• commit 1: implements the fix
• commit 2: reworks the SyncStatus() to sync the entire status and not only conditions

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-cherrypick-robot]

@damdo: new pull request created: #332

Details

In response to this:

/cherry-pick release-4.19

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[openshift-bot]

[ART PR BUILD NOTIFIER]

Distgit: ose-cluster-capi-operator
This PR has been included in build ose-cluster-capi-operator-container-v4.20.0-202507110814.p0.g89f5a58.assembly.stream.el9.
All builds following this will include this PR.