-
Notifications
You must be signed in to change notification settings - Fork 462
baremetal: ipv6, switch to NM dispatcher for DNS VIP prepending #1396
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
baremetal: ipv6, switch to NM dispatcher for DNS VIP prepending #1396
Conversation
5ba4b45 to
99e904f
Compare
|
/lgtm |
|
/assign yboaron |
rgolangh
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good and will address the prepend issues that I saw #1313 - I'm going to add this to oVirt.
templates/worker/00-worker/baremetal/files/NetworkManager-resolv-prepender.yaml
Outdated
Show resolved
Hide resolved
|
/retest |
The prepend via dhclient doesn't work via ipv6, so switch to a NetworkManager dispatcher that runs after dhclient instead as a workaround. Co-Authored-By: Antoni Segura Puimedon <[email protected]>
Make it clear that we're writing /etc/resolv.conf but also reading the /var/run/NetworkManager/resolv.conf
99e904f to
33df2e0
Compare
|
/retest |
|
@hardys: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. DetailsInstructions 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. I understand the commands that are listed here. |
|
/skip |
|
/retest |
Also cc @russellb @derekhiggins who have tested this and found it to work OK - I've also re-tested it in a regular ipv4 environment. |
|
/lgtm |
|
/lgtm |
|
@celebdor @bcrochet @russellb I think we may have to make this also apply to the bootstrap VM, particularly because the NM conf where we set rc-manager=unmanaged in this PR is common? Also we set the prepend dhclient.conf option in the installer here: So I think we need to remove that and ensure the prepender gets added for all nodes including bootstrap? There are only common, master and worker templates directories, how does the precedence work, e.g can we have a common template (which will be for the bootstrap, or perhaps bootstrap and masters if we switch to using the DNS VIP on the bootstrap VM), then override it in the worker directory with a file of the same name? |
It looks like the MCO templates don't apply to the bootstrap VM. I think we need to add what's needed to the installer. |
kikisdeliveryservice
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the update @russellb !
|
/cherrypick release-4.3 |
|
@kikisdeliveryservice: once the present PR merges, I will cherry-pick it on top of release-4.3 in a new PR and assign it to you. DetailsIn 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. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bcrochet, celebdor, hardys, kikisdeliveryservice The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@kikisdeliveryservice: new pull request created: #1406 DetailsIn 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. |
This was previously done with an option to dhclient, but this doesn't work when doing DHCPv6. Switch to a script run by NetworkManager to do the same thing. This matches the same approach moved to by the MCO in this PR: openshift/machine-config-operator#1396
This was previously done with an option to dhclient, but this doesn't work when doing DHCPv6. Switch to a script run by NetworkManager to do the same thing. This matches the same approach moved to by the MCO in this PR: openshift/machine-config-operator#1396
This was previously done with an option to dhclient, but this doesn't work when doing DHCPv6. Switch to a script run by NetworkManager to do the same thing. This matches the same approach moved to by the MCO in this PR: openshift/machine-config-operator#1396
This was previously done with an option to dhclient, but this doesn't work when doing DHCPv6. Switch to a script run by NetworkManager to do the same thing. This matches the same approach moved to by the MCO in this PR: openshift/machine-config-operator#1396
This was previously done with an option to dhclient, but this doesn't work when doing DHCPv6. Switch to a script run by NetworkManager to do the same thing. This matches the same approach moved to by the MCO in this PR: openshift/machine-config-operator#1396
The prepend via dhclient doesn't work via ipv6, so switch to a NetworkManager dispatcher that runs after dhclient instead as a workaround. This ports the BM fix from openshift#1396 to OpenStack platform.
The prepend via dhclient doesn't work via ipv6, so switch to a NetworkManager dispatcher that runs after dhclient instead as a workaround. This ports the BM fix from openshift#1396 to OpenStack platform.
The prepend via dhclient doesn't work via ipv6, so switch to a
NetworkManager dispatcher that runs after dhclient instead as a
workaround.
- What I did
Reworked the prepender implementation (with help from @celebdor) to avoid using the
prepend domain-name-serversoption in dhclient.conf - it seems this option only works for ipv4[1] and the suggested alternative ofprepend dhcp6.name-serversalso doesn't seem to work when the resolv.conf is managed by NetworkManager.Instead we configure NetworkManager to no longer manage the resolv.conf directly, and rely on a dispatcher script which injects the necessary IP on master/worker nodes to correctly reference coredns for the baremetal platform.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=643890
- How to verify it
Deploy with ipv4 and ipv6, confirm that on the masters the DNS VIP is prepended to the resolv.conf, and on the workers the local nic IP for the controlplane network (not the DNS VIP) is configured.
Also check
sudo journalctl -b | grep prependerto see the log output from the dispatcher scripts.- Description for the changelog
For the baremetal platform management of the resolv.conf is now handled via a NetworkManager dispatcher script, so that the necessary DNS server can be prepended for both ipv4 and ipv6 environments.