OPNET-569: Do not run resolv-prepender from NM dispatcher #4654
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@mkowalski: This pull request references OPNET-569 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.18.0" version, but no target version was set. 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. |
|
/test e2e-metal-ipi |
|
@mkowalski: The specified target(s) for
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-ipi-ovn-dualstack |
1 similar comment
|
/test e2e-metal-ipi-ovn-dualstack |
This PR changes the logic of how NetworkManager communicates changes in the environment and how they are picked by on-prem-resolv-prepender. Previously the NM dispatcher script had a logic that would trigger a systemd service (either to start it or to restart). This proven to be problematic, prone to race conditions and in principle a complicated design. Now we are moving to a model where systemd on its own will decide what and when to restart, in our case by leveraging the systemd path units. NM dispatcher is now responsible only for writing a correct environment file (we need that in case DNS search domains change). Systemd path unit observes the file and if a change is detected, it will trigger whatever is necessary. There is other stuff in the NM dispatcher script that we are keeping as it is out of scope of this refactor. Closes: OPNET-569
|
/test e2e-metal-ipi-ovn-dualstack |
|
/test e2e-openstack |
|
/retest-required |
|
/lgtm This removes less code than I expected, but looking through it I don't see anything else that I'm confident we could remove so let's go with this version. I guess it was wishful thinking on my part. :-) |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cybertron, LorbusChris, mkowalski 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
1 similar comment
|
@mkowalski: The following test 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. |
openshift-merge-bot
bot
merged commit b3a562b
into
openshift:master
|
[ART PR BUILD NOTIFIER] Distgit: ose-machine-config-operator |
|
/jira backport release-4.17,release-4.16,release-4.15 |
|
@mkowalski: Missing required branches for backport chain:
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. |
|
/jira backport release-4.18,release-4.17,release-4.16,release-4.15 |
|
@mkowalski: The following backport issues have been created: Queuing cherrypicks to the requested branches to be created after this PR merges: 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. |
|
@openshift-ci-robot: new pull request created: #4783 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. |
|
@openshift-ci-robot: new pull request created: #4784 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. |
|
@openshift-ci-robot: new pull request created: #4785 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. |
|
@openshift-ci-robot: new pull request could not be created: failed to create pull request against openshift/machine-config-operator#release-4.18 from head openshift-cherrypick-robot:cherry-pick-4654-to-release-4.18: status code 422 not one of [201], body: {"message":"Validation Failed","errors":[{"resource":"PullRequest","code":"custom","message":"No commits between openshift:release-4.18 and openshift-cherrypick-robot:cherry-pick-4654-to-release-4.18"}],"documentation_url":"https://docs.github.com/rest/pulls/pulls#create-a-pull-request","status":"422"} 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. |
This PR changes the logic of how NetworkManager communicates changes in the environment and how they are picked by on-prem-resolv-prepender.
Previously the NM dispatcher script had a logic that would trigger a systemd service (either to start it or to restart). This proven to be problematic, prone to race conditions and in principle a complicated design.
Now we are moving to a model where systemd on its own will decide what and when to restart, in our case by leveraging the systemd path units.
NM dispatcher is now responsible only for writing a correct environment file (we need that in case DNS search domains change). Systemd path unit observes the file and if a change is detected, it will trigger whatever is necessary.
There is other stuff in the NM dispatcher script that we are keeping as it is out of scope of this refactor.
Closes: OPNET-569