network interfaces are 'up' automatically

[smoser]

$ dpkg-query --show lxd lxc2
lxc2    2.0.1-0ubuntu1
lxd 2.0.1-0ubuntu1
$ lxc init xenial x1
$ lxc-chroot x1 cat /sys/class/net/eth0/operstate
up
$ lxc-chroot x1 ifconfig
eth0      Link encap:Ethernet  HWaddr 00:16:3e:7d:ab:de  
          inet6 addr: fe80::216:3eff:fe7d:abde/64 Scope:Link
          inet6 addr: fdec:2922:2f07:0:216:3eff:fe7d:abde/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:29 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4543 (4.5 KB)  TX bytes:750 (750.0 B)

why is my network device 'up' when nothing in my init system has configured it so?
i've attached lxc-chroot, it just does a container without a real init system to avoid booting the system but still look around inside.

lxc-chroot.txt

[stgraber]

That's been done by default for all LXC containers for the past 4 years or so (at least).

We've replicated the logic in LXD as a bunch of LXC containers based on busybox or similar seem to expect it.

[stgraber]

Is this behavior causing some kind of problem for you?

[smoser]

 # cat /var/lib/cloud/seed/nocloud-net/network-config 
version: 1
config:
    - type: physical
      name: eth0
      subnets:
          - type: dhcp
            control: auto

that is the default config that 'lxc launch xenial' will render. but if the user provides something that says 'name' of 'en0' then cloud-init wants to do what the user said and rename that device to 'en0'.
it can't do that if the network device is already up.

it seems like "layering violation" of sorts for lxd to bring network devices up.
any ideas on what I could do in cloud-init short of just saying "if i'm in a container, then feel free to take network devices down before renaming"? note, that'd probably foobar whatever reason you had for bringing them up in the first place.

[stgraber]

Well, I suspect the reason to bring it up in the first place was for containers that didn't run cloud-init or in fact any kind of network configuration tool. In such case, the interface would be brought up and get a functional IPv6 address + link-local address from the kernel.

I don't think special-casing containers in cloud-init is the right answer, but maybe you can bring the interface down for rename if it doesn't have any manually configured address yet?

You can check that (properly ignores automatic addresses and link local) with:

• ip -4 addr show dev eth0 permanent scope global
• ip -6 addr show dev eth0 permanent scope global

This would also cover the case where on a normal system, something in the initrd brought the interface up and didn't bring it back down before switching to init (I don't believe we have such a thing in default Ubuntu, but it's not impossible).

[smoser]

For later reference, cloud-init now will feel free to take an interface down if the only addresses it has are as listed above and it needs to rename the interface. If it took it down, it will bring it back up.