need to support renaming of devices in container and on first boot

Bug #1579130 reported by Scott Moser
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cloud-init (Ubuntu)
Fix Released
High
Scott Moser
Xenial
Fix Released
High
Scott Moser
systemd (Ubuntu)
Invalid
Wishlist
Unassigned

Bug Description

We're interested in supporting network configuration of cloud instances including lxc containers via maas/cloud-init yaml format.

For Containers, the end goal is to do:
$ lxc init xenial x1
$ ncpath=/var/lib/cloud/seed/nocloud-net/network-config
$ sudo tee /var/lib/lxd/containers/x1/rootfs/$ncpath <<EOF
version: 1
config:
  - type: physical
    mac_address: "00:16:3e:3b:01:7a"
    name: foo2
    subnets:
      - type: dhcp
        control: auto
EOF

$ lxc start x1
$ lxc exec x1 /bin/bash

From inside we expect to have a device named 'foo2' at this point that has dhcp'd.

Currently cloud-init is writing files named:
 /etc/systemd/network/50-cloud-init-eth0.link
and expecting systemd.link(5) to rename them.

We've run into a number of issues with this.
 a.) we don't get coldplug events for devices in a container, so writing systemd.link (or 70-persistent-net.rules style udev rules files) wont "just work" to apply the name changes.

 b.) systemd.link does not rename devices that have been renamed previously, and all lxd instance devices are renamed (from the kernel returned veth<random> into 'eth0').
 That is implemented by check of /sys/devices/virtual/net/eth0/name_assign_type . Value of 4 means renamed.

 c.) systemd.link will not attempt to rename a device that does not have a driver.
   To see that run: udevadm test-builtin net_setup_link /sys/class/net/eth0
   http://paste.ubuntu.com/16261974/

 d.) on first boot of a cloud instance, the systemd.link files in the initramfs are either pristine or from the previous instance. The devices will leave the initramfs either named incorrectly or named with standard persistent naming and will have already been renamed.

To force these systemd.link files to run in spite of 'b' on kvm guests or bare metal, we have found that unbind and rebind of the device will clear the state and rename would occur. that can be done as shown in https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1577844/comments/3 but since there is no 'driver' we cannot unbind and rebind veth devices.

To do this right, we need to support:
 1.) renaming on first boot with initramfs and with 'stale' initramfs
 2.) renaming in lxc containers
 3.) user updating whatever files or mechanism is used post first boot. For example, if the user wrote a 25-my-rules.link after first boot, a reboot should prefer their provided names to whatever were originally there.
 4.) if cloud-init networking is disabled, the renaming should not occur.

Related Bugs:
 * bug 1594546: no need to write systemd.link files

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: udev 229-4ubuntu4
ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
Uname: Linux 4.4.0-21-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
Date: Fri May 6 15:42:52 2016
MachineType: LENOVO 33672B7
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-21-generic.efi.signed root=UUID=19ac97d5-6973-4193-9a09-2e6bbfa38262 ro quiet splash vt.handoff=7
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/18/2013
dmi.bios.vendor: LENOVO
dmi.bios.version: G8ET96WW (2.56 )
dmi.board.asset.tag: Not Available
dmi.board.name: 33672B7
dmi.board.vendor: LENOVO
dmi.board.version: Not Defined
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvrG8ET96WW(2.56):bd12/18/2013:svnLENOVO:pn33672B7:pvrThinkPadX131e:rvnLENOVO:rn33672B7:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 33672B7
dmi.product.version: ThinkPad X131e
dmi.sys.vendor: LENOVO

Related branches

Revision history for this message
Scott Moser (smoser) wrote :
Scott Moser (smoser)
description: updated
Changed in cloud-init (Ubuntu):
status: New → Confirmed
importance: Undecided → High
description: updated
description: updated
Martin Pitt (pitti)
Changed in systemd (Ubuntu):
status: New → Triaged
assignee: nobody → Martin Pitt (pitti)
Scott Moser (smoser)
description: updated
Scott Moser (smoser)
summary: - need to support systemd.link renaming of devices in container
+ need to support renaming of devices in container and on first boot
Scott Moser (smoser)
description: updated
Revision history for this message
Alberto Salvia Novella (es20490446e) wrote :

@ Martin Pitt

Please check if bug importance is correct.

Changed in systemd (Ubuntu):
importance: Undecided → High
importance: High → Wishlist
Revision history for this message
Scott Moser (smoser) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cloud-init - 0.7.7~bzr1227-0ubuntu1

---------------
cloud-init (0.7.7~bzr1227-0ubuntu1) yakkety; urgency=medium

  * New upstream snapshot.
    - fix one more unit test to run inside buildd.

 -- Scott Moser <email address hidden> Sat, 04 Jun 2016 20:55:07 -0400

Changed in cloud-init (Ubuntu):
status: Confirmed → Fix Released
Scott Moser (smoser)
description: updated
Revision history for this message
Scott Moser (smoser) wrote :

Hello,
An SRU upload of cloud-init for 16.04 that contains a fix for this bug has been made under bug 1595302. Please track that bug if you are interested.

Changed in cloud-init (Ubuntu Xenial):
importance: Undecided → High
status: New → In Progress
no longer affects: systemd (Ubuntu Xenial)
Changed in cloud-init (Ubuntu):
assignee: nobody → Scott Moser (smoser)
Changed in cloud-init (Ubuntu Xenial):
assignee: nobody → Scott Moser (smoser)
Revision history for this message
Scott Moser (smoser) wrote :

fix is now released to xenial under bug 1595302. daily cloud-images with this newer version of cloud-init should appear in the next few days. Any image with a serial number *newer* than 20160707 should have cloud-init at 0.7.7~bzr1246-0ubuntu1~16.04.1 .

Changed in cloud-init (Ubuntu Xenial):
status: In Progress → Fix Released
Martin Pitt (pitti)
Changed in systemd (Ubuntu):
assignee: Martin Pitt (pitti) → nobody
Revision history for this message
Dan Streetman (ddstreet) wrote :

please reopen if this is still an issue

Changed in systemd (Ubuntu):
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.