OCPBUGS-56211: Boot Image Controller should not degrade when golden configmap is slow to update

[djoshy]

- What I did
I removed the wait loop for the golden configmap stamp in the MSBIC. Instead, the controller will exit the sync and attempt to resync again when the confgimap is updated. This means that the MSBIC will no longer degrade if the master pool takes a while to update, which can be due to myriad of issues, and typically not boot image related.

- How to verify it
Existing e2es should pass. This should not cause any substantial changes in the MSBIC's actual update behavior. The MSBIC should no longer degrade if the golden configmap never gets stamped, but I'm fairly confident we weren't directly testing for this failure mode.

[openshift-ci-robot]

@djoshy: This pull request references Jira Issue OCPBUGS-56211, 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.

In response to this:

- What I did
I removed the wait loop for the golden configmap stamp in the MSBIC. Instead, the controller will exit the sync and attempt to resync again when the confgimap is updated. This means that the MSBIC will no longer degrade if the master pool takes a while to update, which can be due to myriad of issues, and typically not boot image related.

- How to verify it
Existing e2es should pass. This should not cause any substantial changes in the MSBIC's actual update behavior. The MSBIC should no longer degrade if the golden configmap never gets stamped, but I'm fairly confident we weren't directly testing for this failure mode.

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.

[djoshy]

/jira refresh

[openshift-ci-robot]

@djoshy: This pull request references Jira Issue OCPBUGS-56211, 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 @sergiordlr

In response to this:

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

[openshift-ci]

@djoshy: The following tests 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/e2e-azure-ovn-upgrade-out-of-change	b2976fe	link	false	/test e2e-azure-ovn-upgrade-out-of-change
ci/prow/e2e-gcp-op-ocl	b2976fe	link	false	/test e2e-gcp-op-ocl

Full PR test history. Your PR dashboard.

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.

[yuqi-zhang]

/lgtm

Any issues that arise from this should be degrading elsewhere as we discussed, so I think there's no scenario where this failure would specifically be helpful for the user.

/hold

for pre-merge qe verification, if necessary

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: djoshy, yuqi-zhang

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [djoshy,yuqi-zhang]

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

[djoshy]

Chatted on slack with @ptalgulk01 , Given that this is not easy to test, we will skip premerge QE. Going to run payloads for extra safety:

/payload-job periodic-ci-openshift-release-master-ci-4.20-e2e-aws-ovn-serial periodic-ci-openshift-release-master-ci-4.20-e2e-gcp-ovn-serial

[openshift-ci]

@djoshy: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command

• periodic-ci-openshift-release-master-ci-4.20-e2e-aws-ovn-serial

See details on https://pr-payload-tests.ci.openshift.org/runs/ci/818d3cc0-3243-11f0-9c19-beaf7395377b-0

[djoshy]

/payload-job periodic-ci-openshift-release-master-ci-4.20-e2e-aws-ovn-serial periodic-ci-openshift-release-master-ci-4.20-e2e-gcp-ovn-serial

[openshift-ci]

@djoshy: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command

• periodic-ci-openshift-release-master-ci-4.20-e2e-aws-ovn-serial

See details on https://pr-payload-tests.ci.openshift.org/runs/ci/96564840-3243-11f0-9f71-c8ea3ad31035-0

[djoshy]

/payload-job periodic-ci-openshift-release-master-nightly-4.20-e2e-gcp-ovn-serial

[openshift-ci]

@djoshy: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command

• periodic-ci-openshift-release-master-nightly-4.20-e2e-gcp-ovn-serial

See details on https://pr-payload-tests.ci.openshift.org/runs/ci/d26000b0-3243-11f0-8fed-e908061c32cf-0

[djoshy]

/cherry-pick release-4.19 release-4.18 release-4.17

[openshift-cherrypick-robot]

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

In response to this:

/cherry-pick release-4.19 release-4.18 release-4.17

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.