Skip to content
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

Backport of cni: fix regression in falling back to DNS owned by dockerd into release/1.5.x #20191

Merged
merged 1 commit into from
Mar 22, 2024

Conversation

hc-github-team-nomad-core
Copy link
Contributor

Backport

This PR is auto-generated from #20189 to be assessed for backporting due to the inclusion of the label backport/1.5.x.

🚨

Warning automatic cherry-pick of commits failed. If the first commit failed,
you will see a blank no-op commit below. If at least one commit succeeded, you
will see the cherry-picked commits up to, not including, the commit where
the merge conflict occurred.

The person who merged in the original PR is:
@tgross
This person should manually cherry-pick the original PR into a new backport PR,
and close this one when the manual backport PR is merged in.

merge conflict error: POST https://api.github.com/repos/hashicorp/nomad/merges: 409 Merge conflict []

The below text is copied from the body of the original PR.


In #20007 we fixed a bug where the DNS configuration set by CNI plugins was not threaded through to the task configuration. This resulted in a regression where a DNS override set by dockerd was not respected for bridge mode networking. Our existing handling of CNI DNS incorrectly assumed that the DNS field would be empty, when in fact it contains a single empty DNS struct.

Handle this case correctly by checking whether the DNS struct we get back from CNI has any nameservers, and ignore it if it doesn't. Expand test coverage of this case.

Fixes: #20174


In addition to the unit tests here, I verified this works with the Docker DNS override. Using the default values for dockerd and this patch, I get the following in a Nomad job using mode="bridge" networking:

$ docker exec -it 8b38 cat /etc/resolv.conf
# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.

nameserver 208.67.222.222
nameserver 208.67.220.220
nameserver 192.168.1.1
search mynetworksettings.com

# Based on host file: '/run/systemd/resolve/resolv.conf' (legacy)
# Overrides: []

And after setting an override of --dns=8.8.8.8 in my docker.service unit, I get the following for the same job:

$ docker exec -it ec42 cat /etc/resolv.conf
# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.

nameserver 8.8.8.8
search mynetworksettings.com

# Based on host file: '/run/systemd/resolve/resolv.conf' (legacy)
# Overrides: [nameservers]

Overview of commits

@hashicorp-cla
Copy link

hashicorp-cla commented Mar 22, 2024

CLA assistant check
All committers have signed the CLA.

@vercel vercel bot temporarily deployed to Preview – nomad March 22, 2024 14:56 Inactive
In #20007 we fixed a bug where the DNS configuration set by CNI plugins was not
threaded through to the task configuration. This resulted in a regression where
a DNS override set by `dockerd` was not respected for `bridge` mode
networking. Our existing handling of CNI DNS incorrectly assumed that the DNS
field would be empty, when in fact it contains a single empty DNS struct.

Handle this case correctly by checking whether the DNS struct we get back from
CNI has any nameservers, and ignore it if it doesn't. Expand test coverage of
this case.

Fixes: #20174
@tgross tgross force-pushed the backport/b-cni-dns-regression/oddly-nice-gar branch from 5685d02 to 2128529 Compare March 22, 2024 14:57
@tgross tgross marked this pull request as ready for review March 22, 2024 14:57
@tgross tgross merged commit 11e81d1 into release/1.5.x Mar 22, 2024
23 of 25 checks passed
@tgross tgross deleted the backport/b-cni-dns-regression/oddly-nice-gar branch March 22, 2024 15:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants