Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
cni: add DNS set by CNI plugins to task configuration #20007
cni: add DNS set by CNI plugins to task configuration #20007
Changes from 1 commit
cbf24df
1fb1dd2
bf3e122
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
While I understand the goal here, I am not sure if merging DNS is the proper way to go here. For instance if
options
hasrotate
set then there would be no guarantee that the first server is actually used. https://developer.hashicorp.com/nomad/docs/job-specification/network#dns also says that the defaults from the client host are used, so we don't necessarily know what is set etc… I fear that this might end up being a bit fragile.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.
As you've noted, there are three potential sources for DNS configuration here: the output of CNI plugins, the user-provided DNS config, and whatever is on the client. This code path only involves the first two. The task driver is then responsible for what happens after that... the built-in task drivers use
GenerateDNSMount
to create the/etc/resolv.conf
. (So for example, you could have a third-party task driver that requires a particular CNI plugin be used, in which case it'd use that value alone and not get anything from the client host.)All that being said, any DNS configuration from the CNI plugins is frankly likely to conflict with any jobspec
network.dns
configuration. Our default network configuration forbridge
networking doesn't generate any DNS values. So if you're intentionally using a CNI plugin that does, you should know not to set conflicting values on thenetwork.dns
block. Otherwise yes, it's fragile... we want to give users knobs here but its up to them to use them responsibly.Could definitely do with some warnings around
network.dns
usage in the docs though.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.
I'm having second thoughts on the order though here... lemme get some input from the team on that. (And happy to hear your thoughts as well!)
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.
So since DNS is usually at fault when there are issues I'd prefer a "stable" configuration like the following:
.consul
In a perfect world I'd love to be able to customize the template for the default bridge CNI configuration (with and without tproxy) so I could globally override that for all bridge users without having to go into every task and change mode to
cni/my_cni
.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.
Aye, that's pretty much what the rest of the Nomad team suggested we do here, so I was definitely off the rails a bit 😀
Definitely an interesting idea. A little challenging from the perspective of fingerprinting, because if there's behavior the application needs from that specific bridge configuration there's no reasonable way for us to tell the server which clients have that configuration set.
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.
Not sure why this would require fingerprinting. In it's easiest implementation one could just specify an alternate template in the client-configuration for
nomad/client/allocrunner/networking_bridge_linux.go
Line 152 in 20cfbc8
We could even add cni_consul to that list by default (assuming nomad) ships it or so and have it activate/deactivate based on cni args. This way the same template could be used independent of whether tproxy is used or not.