Ubuntu
cloud-init package

Can't bring up a machine on a dual network (ipv4 and ipv6)

Bug #1635716 reported by Mathieu Trudel-Lapierre on 2016-10-21

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	cloud-init (Ubuntu)	Invalid	Medium	Unassigned

Bug Description

Trying to bring up a system with both IPv4 and IPv6 available should be generating files in /run/net6-$iface.conf and /run/net-$iface.conf.

Both of these files may contain the DEVICE variable, as well as HOSTNAME and DNSDOMAIN.

I made some small changes to the dhclient hook for the initramfs to write that to both, since it does make sense for both IP protocols. However, this causes cloud-init to fail since the device name is defined in both files (ValueError, "defined multiple times" -- see screenshot).

Related bugs:
* bug 1621507: initramfs-tools configure_networking() fails to dhcp ipv6 addresses
* bug 1621615: network not configured when ipv6 netbooted into cloud-init

See original description

Related branches

~smoser/cloud-init:bug/1635716-initrd-cfg-net6

Rejected for merging into cloud-init:master

cloud-init Commiters: Pending requested 2016-10-24

Revision history for this message

Mathieu Trudel-Lapierre (cyphermox) wrote on 2016-10-21:

Screenshot_generic-2_2016-10-21_16:09:30.png Edit (15.4 KiB, image/png)

affects:

maas (Ubuntu) → cloud-init (Ubuntu)

Revision history for this message

Scott Moser (smoser) wrote on 2016-10-24:

Hi, this is new functionality, and cloud-init is being reasonable in its assertion as in any existing behavior this would be an error.

Please provide some examples of net6-eth0.conf and net-eth0.conf that should work together, and your expected result.

Revision history for this message

Mathieu Trudel-Lapierre (cyphermox) wrote on 2016-10-24:

net-eth0.conf:

DEVICE=eth0
HOSTNAME=mysystem
IPV4ADDRESS=10.10.10.10
[...]

net6-eth0.conf:

DEVICE=eth0
HOSTNAME=mysystem
IPV6ADDRESS=fe80:dead:beef::fe
[...]

The concept of DEVICE, HOSTNAME, and DNSDOMAIN are universal; DHCP may provide a hostname and domain name as a response when assigning an IP address, and the device used can be useful to have in both the IPv4 and IPv6 case -- we should assume that anything that is relevant to IPv4 that isn't specific to IPv4 will still be relevant in the world of IPv6 for any software that expects to bring up a remote rootfs.

If cloud-init is making an assumption that a specific key such as DEVICE is specific to IPv4, that is an incorrect assumption and needs to be fixed to properly support IPv6 in a separate file than IPv4 settings in the initramfs.

Scott Moser (smoser) on 2016-10-24

description:

updated

Scott Moser (smoser) on 2016-10-24

Changed in cloud-init (Ubuntu):
status:	New → Confirmed
importance:	Undecided → Medium

Revision history for this message

Scott Moser (smoser) wrote on 2016-11-02:

I've just took a read of the code that landed. Over all, the new code is much more suitable for SRU. I think it still has some issues though.

a.) we use 'grep' and 'cat' extensively in the new code. Most could be replaced with case statements or other shell builtin such as 'case' and 'read' and avoid subprocesses and their overhead. This is not broken, but slower boot as a result.

b.) ipconfig would set the 'hostname' in the dhcp request to the value in the 5th token of ip=. I do not believe that is being done now.

c.) at least 1 dhclient process will end up running after exiting the initramfs exits, and won't' have access to its open files. I'm not sure what the behavior will be, but its possible that this process could decide at re-lease time to take the interface down since it would not have its lease database around. I say at least due to bug 1633619. If we ever re-try, I suspect we'll have one for each loop.

Do we know what happens to this uprooted dhclient process?

d.) The ipconfig path that was left on will now have 'sleep's inserted and will as a result take much longer than necessary if it ever does not get a lease on the first try.

'b' is definitely a change in behavior. We really need to know what happens on 'c', and 'd' seems like it should be fixed as it negatively affects the 'ip=' path.

Revision history for this message

Scott Moser (smoser) wrote on 2016-11-02:

the above comment was meant for bug 1621507. i've commented there.

Revision history for this message

Scott Moser (smoser) wrote on 2016-11-02:

Because the implementation changed, this is not really a problem.
DEVICE6 and DEVICE is now used instaed.

Lamon'ts fix to address that is in https://code.launchpad.net/~lamont/cloud-init/+git/bug-1621615-device6/+merge/309718