~raharper/cloud-init:fix/lp-1766287-detect-unstable-names

Last commit made on 2018-04-26
Get this branch:
git clone -b fix/lp-1766287-detect-unstable-names https://git.launchpad.net/~raharper/cloud-init
Only Ryan Harper can upload to this branch. If you are Ryan Harper please log in for upload directions.

Branch merges

Branch information

Name:
fix/lp-1766287-detect-unstable-names
Repository:
lp:~raharper/cloud-init

Recent commits

4b1de1d... by Ryan Harper

unittest: add unittest for util.udevadm_settle

4130502... by Ryan Harper

mock util.udevadm_settle instead of util.subp

66fa34c... by Ryan Harper

Consolidate udevamd settle to util, fix callers

fa69076... by Ryan Harper

net.is_renamed: all values of 3 and 4 to be renamed

- Add documentation to the method on the meaning of the values
- Switch to device != 'lo' vs device not in ['lo']
- Remove debugging 'WARK' statement

9f93fcc... by Ryan Harper

Mock out subp call to udevadm settle in net/tests/test_init.py

6eaf5e9... by Ryan Harper

net: detect unstable network names and trigger a settle if needed

The cloud-init-local.service expects that any network device name
changes have already been completed by the kernel or udev daemon.

In some situations we've found that the renaming of interfaces from
kernel names (eth0, eth1, etc) to their persistent names (eno1, ens3,
enp0s1, etc) may happen after cloud-init-local has started where it
reads values from sysfs about what network devices are present, and
which device to use as a fallback nic.

Subsequently, cloud-init-local would write out network configuration
for a kernel device name which would no longer be present by the time
that networking services start to bring up the devices. The result is
that the instance does not get networking configured. Prior to use of
systemd-networkd, the Ubuntu 'networking.service' unit included a call
to udevadm settle which is why this race is not seen on a Xenial
system.

This change adds the ability to detect if an interface has a stable
name, if if we find one without stable names and stable names have not
been disabled (net.ifnames=0 in /proc/cmdline), then cloud-init will
invoke udevadm settle.

LP: #1766287

b73559e... by Scott Moser

IBMCloud: improve documentation in datasource.

This adds information to the IBMCloud datasource describing the
6 different scenarios that it is expected to handle.

a57928d... by Vitaly Kuznetsov

sysconfig: dhcp6 subnet type should not imply dhcpv4

BOOTPROTO=dhcp in sysconfig enables DHCPv4 and we should not do this
implicitly when 'dhcp6' subnet is specified. In case both dhcpv4 and
dhcpv6 are needed users should specify both:
    subnets:
      - type: dhcp6
      - type: dhcp

Fix the current code and add a dhcpv6 only test.

Signed-off-by: Vitaly Kuznetsov <email address hidden>

00d7b9c... by Scott Moser

packages/debian/control.in: add missing dependency on iproute2.

Ubuntu minimal images do not have iproute2, so correctly identify
our dependency on it.

LP: #1766711

4ed1645... by Mike Gerdts

DataSourceSmartOS: add locking of serial device.

cloud-init and mdata-get each have their own implementation of the
SmartOS metadata protocol. If cloud-init and other services that call
mdata-get are run concurrently, crosstalk on the serial port can cause
them both to become confused.

This change makes it so that cloud-init uses the same cooperative
locking scheme that's used by mdata-get, thus preventing cross-talk
between mdata-get and cloud-init.

For testing, a VM running on a SmartOS host and pyserial are required.
If the tests are run on a platform other than SmartOS, those that use a
real serial port are skipped. pyserial remains commented in
requirements.txt because most testers will not be running atop SmartOS.

LP: #1746605