openshift-ci-robot
commented
1 month ago @yuqi-zhang: This pull request references Jira Issue OCPBUGS-35300, which is valid.
3 validation(s) were run on this bug
* bug is open, matching expected state (open) * bug target version (4.17.0) matches configured target version for branch (4.17.0) * bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)No GitHub users were found matching the public email listed for the QA contact in Jira (hlipsig+1@redhat.com), skipping review request.
The bug has been updated to refer to the pull request using the external bug tracker.
In response to [this](https://github.com/openshift/machine-config-operator/pull/4423):
>This was originally reordered such that ovs-configuration was able to run when the reboot was skipped. See: https://github.com/openshift/machine-config-operator/pull/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).
>
>This fix aims to apply just to Azure, which is not ideal since it drifts the service definition, but if don't-reboot-on-metal and ARO have different dependency chains, this is the easiest middle ground.
>
>
>
>**- What I did**
>
>**- How to verify it**
>
>**- Description for the changelog**
>
>
Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=openshift%2Fmachine-config-operator). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
openshift-ci[bot]
yuqi-zhang
sdodson
openshift-cherrypick-robot
openshift-bot
This was originally reordered such that ovs-configuration was able to run when the reboot was skipped. See: https://github.com/openshift/machine-config-operator/pull/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).
This fix aims to apply just to Azure, which is not ideal since it drifts the service definition, but if don't-reboot-on-metal and ARO have different dependency chains, this is the easiest middle ground.
- What I did
- How to verify it
- Description for the changelog