-
Notifications
You must be signed in to change notification settings - Fork 18.7k
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
Vendoring libnetwork #19198
Vendoring libnetwork #19198
Conversation
- replace /etc/hosts based name resolution with embedded DNS for user defined networks - overlay veth cleanup: moby#18814 - check before programming ipv6 in bridge: moby#19139 - diable DAD: moby#18871 Signed-off-by: Santhosh Manohar <santhosh@docker.com>
Signed-off-by: Santhosh Manohar <santhosh@docker.com>
Just pasting the line diff here as GitHub can't show it:
Even among the dependencies, the bulk comes from
|
As far as I can tell the only important Engine side impact to have in mind is this one. I haven't tested yet, but code LGTM. |
@sanimej There is misspell in commit message - "diable DAD" |
@LK4D4 Corrected the typo. |
if ep != nil && strings.Split(h, ".")[0] == ep.Name() { | ||
continue | ||
} | ||
|
||
recs = append(recs, etchosts.Record{ | ||
Hosts: h, | ||
IP: ip.String(), | ||
IP: ip[0].String(), |
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.
Will this ever panic?
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.
no. there wont be a case when ip[0] would be nil.
having said that, there are some paths in the code that requires the svcMap should be locked during certain operations. We are tracking that to be fixed.
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.
infact, this function is currently of no use (since we moved away from /etc/hosts) and we can even remove that,
@sanimej is that correct ?
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.
@mavenugo Yes, the call to delete the service records from /etc/hosts is not necessary. What has to be removed is the self entry for IP of the endpoint that is being disconnected. This is a known issue. Will push a PR to address these.
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.
Off topic, but we should really make sure that "no longer updating /etc/hosts
" is explicitly mentioned in the changelog/release notes. I already had someone reporting that they currently have a filewatcher on /etc/hosts
to automate things 😕
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.
@sanimej thanks. Just to make sure we are clear, this PR isn't dependent on that change and it can go in independently.
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.
@thaJeztah yes. this is a good candidate for release-notes. Added the changelog tag to reflect this.
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.
Yes. This PR has no dependency on the change referred to in this comment.
ping @jfrazelle @calavera @tonistiigi can you please have a look at this one; it's important for libnetwork to move forward |
LGTM 🐰 |
For documentation changes; does this also affect the way classic links work (I.e. are the aliases no longer written to |
@thaJeztah Tried the PR out and yes, |
Yes, let's do it this way to unblock Madhu. Thanks @vdemeester! |
sgtm! I'll open an issue |
Opened #19221 to track docs changes |
thanks @icecrime @thaJeztah @vdemeester
There is no change to the classic links (in bridge network). We certainly have to document the newly added |
@mavenugo clear, thanks! |
Couple of issues/questions with the dns discovery:
|
This is because of an incorrect check during network correct. I will push a PR shortly to fix this.
So far (with /etc/hosts) we didn't have service discovery for IPv6. Currently the same behavior is maintained. But it should be possible to support AAAA queries with minimal changes. I am working on that..
PTR record typically gives the complete name. Also, in cases where service name exists on more than one network the container is connected to this can be used as a quick way to see in which network the name is getting resolved.
Embedded DNS server directly interfaces with the host resolvers which doesn't cache the replies (apps might do; but they don't see the TTL value). So the TTL from embedded server is not of much significance. It might be relevant if someone runs a caching DNS server inside the container and have that talk to the embedded server. In that case also 30 mins seems to be a reasonable number. |
What do mean by "apps don't see TTL value"? |
apps use a resolver library and won't see the DNS reply directly. |
Changes include..
Fixes #18814
Fixes #19139
Fixes #18871