This repository has been archived by the owner on May 1, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 43
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Ensured lxdock can work with IPv6 only containers
- Loading branch information
Morgan Aubert
committed
May 31, 2017
1 parent
67c125b
commit 8e51302
Showing
3 changed files
with
11 additions
and
8 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
8e51302
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.
@hsoft The function just returns the IP associated with a container, so I don't see why this change could introduce a regression (the IPv4 address is still returned with a priority over the IPv6 address). If the container is offline the function still returns the correct IP.
8e51302
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.
What do you mean by "offline"? I'm not sure to see your point here.
8e51302
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've made some tests using LXD with a bridge configured for IPv6 only. I wasn't able to properly use LXDock with this configuration because it was looking for IPv4 addresses only. This is why I introduced this little change. At least this allows you to have simple LXDock projects working. eg:
That said problems can appear because the tools used by LXD don't automatically add entries for the IPv6 gateway in the
/etc/resolv.conf
file. This is the only thing that can cause problem with provisioning because DNS resolutions won't work in the containers. The first step was to fix thisget_ip
function. The second step will be to figure out why the nameserver entry is not added when the bridge used by the container is IPv6 only.8e51302
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 can see in the commit, the IPv4 address will be returned with a priority over a potential IPv6 address. IPv4 / IPv6 addresses are fetched from the
eth0
iface (which is a limited behaviour, but this is another problem). So there is no possible scenario where the IPv6 address would be used by LXDock if the considered container has both an IPv4 address and an IPv6 address.I don't think that adding an option to force containers to use IPv6 would be the way to go. The rationale behind this is that a project should work the same way if the LXD bridge is configured for IPv4 only, IPv6 only or IPv4+IPv6. LXDock shouldn't make too much assumptions regarding the configuration of LXD if this is not necessary. In the present case, my feeling is that this is not necessary.
8e51302
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.
If LXD is configured to use a bridge supporting both IPv4 and IPv6, the containers will end up having IPv4 and IPv6 addresses. I'm not sure how to try to produce the glitch you're presenting. Are we tabling on a bug of LXD that would start containers without having both IPv4 / IPv6 addresses at the same time?
In any case, we are debating assumptions here. I propose that we try to reproduce the glitch you're talking about - and then fix the function if this is applicable. When you say "after a lot of lxdock up", are you thinking of a scenario of the form:
???