OCPBUGS-35300: MCD-pull: run after network-online.target again #4422
Conversation
This was originally reordered such that ovs-configuration was able to run when the reboot was skipped. See: openshift#3858 This broke ARO since they require the network to be ready for the pull to happen (and generally, probably best for the network to be ready before attempting to pull the new OS image). Since the services have changed since then, ovs-configuration no longer depends on the existence of the firstboot file, so we should be able to untangle this dependency.
openshift-ci
bot
added
the
do-not-merge/work-in-progress
|
Skipping CI for Draft Pull Request. |
openshift-ci-robot
added
jira/valid-reference
|
@yuqi-zhang: This pull request references Jira Issue OCPBUGS-35300, which is valid. The bug has been moved to the POST state. 3 validation(s) were run on this bug
No GitHub users were found matching the public email listed for the QA contact in Jira ([email protected]), skipping review request. The bug has been updated to refer to the pull request using the external bug tracker. In response to this:
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. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 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:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
|
/test e2e-gcp-op |
openshift-ci
bot
removed
the
do-not-merge/work-in-progress
|
Since this might affect the functionality introduced in #3858, @sergiordlr would you be able to test whether this breaks that or not? ARO verified that this works for them on 4.14 If not, @ori-amizur could you find someone to verify that this wouldn't break bare metal non-reboot installs? Thanks! |
We are going to test tomorrow, but I made a quick test today. It seems that one of the masters failed to complete installation - (crio service failed to start). |
|
/test ? |
|
@sdodson: The following commands are available to trigger required jobs:
The following commands are available to trigger optional jobs:
Use
In response to this:
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. |
|
/test e2e-metal-assisted |
|
@yuqi-zhang: The following tests failed, say
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. |
|
Made 2 tests - both failed. It means this change causes assisted installer to fail installations. |
|
Thanks for testing. We can for now make it Azure only via #4423 instead, and then circle back on this I guess. I don't really see another good option. @ori-amizur were you able to capture why it failed? |
I tried to look briefly at the cluster but I didn't find the reason it failed. |
|
This will break other things, so closing in favour of other solutions |
This was originally reordered such that ovs-configuration was able to run when the reboot was skipped. See: #3858
This broke ARO since they require the network to be ready for the pull to happen (and generally, probably best for the network to be ready before attempting to pull the new OS image).
Since the services have changed since then, ovs-configuration no longer depends on the existence of the firstboot file, so we should be able to untangle this dependency.
- What I did
- How to verify it
- Description for the changelog