Revert "RFE-2962: configure ovs should use node-ip-hint set by nodeip-configuration service" #3360
Conversation
…-configuration service"
|
/payload 4.12 ci blocking |
|
@dgoodwin: trigger 4 job(s) of type blocking for the ci release of OCP 4.12
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/e7e0cac0-4310-11ed-9856-2bbcd6ea1ecd-0 |
|
In the original PRs presubmits, I think we can see our regression on an optional azure job: https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift_machine-config-operator/3233/pull-ci-openshift-machine-config-operator-master-e2e-azure-ovn-upgrade/1575170114657980416 Looking likely this is the PR that introduced the regression on Azure. |
|
/approve |
openshift-ci
bot
added
the
approved
|
cc @tsorya |
I guess it was masked by the 25% pass rate of that job. |
When you say that serial console looks fine, that's for a pre-upgrade boot right? I don't see the console after upgrade I think. |
|
The payload testing seems to confirm it https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/aggregator-periodic-ci-opensh[…]from-stable-4.11-e2e-azure-sdn-upgrade/1576901335637299200 finished about an hour sooner and the upgrade completed The failures there now look related to the kubelet update /lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters, dgoodwin, stbenjam 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 |
|
/test ? |
|
@tsorya: 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/test-infra repository. |
|
/test e2e-azure-ovn-upgrade |
|
/test e2e-azure-upgrade |
|
I believe the evidence points strongly to this PR being the source of the breakage. We don't need the additional azure signal, we already got it from the payload command above. Looking at the history on this PR https://prow.ci.openshift.org/pr-history/?org=openshift&repo=machine-config-operator&pr=3360, and the payload signal I'm confident reverting this is safe. /override ci/prow/e2e-openstack |
|
@stbenjam: Overrode contexts on behalf of stbenjam: ci/prow/e2e-aws, ci/prow/e2e-openstack 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/test-infra repository. |
Reverts #3233
This is a test, we've got a regression in https://issues.redhat.com/browse/OCPBUGS-1906 likely caused by something in this list: https://sippy.dptools.openshift.org/sippy-ng/release/4.12/tags/4.12.0-0.ci-2022-09-29-133725/pull_requests
Workers are upgrading and rebooting fine, but one master attempts it's reboot, then never comes back. No other masters are attempted. Serial console looks ok.