[01:09] <cyphermox> smoser: blackboxsw: rharper: I would have guessed that your network device is not virtio, but that shouldn't be a big deal /now/ since E1000 is also enabled in this case, and that looks like it's been detected.
[01:28] <smoser> cyphermox: well i had actually attached *no* network devices. which clearly should mean "all networking that will be configured is configured".
[01:32] <cyphermox> smoser: I saw your command-line, but I don't think it behaved quite as expected
[01:33] <cyphermox> or I don't understand what the kernel does, because it tries to rename an ens3 or eth0 that isn't there.
[01:37] <smoser> what command line?
[01:37] <smoser> there is no network device.
[01:38] <smoser> i blieve there is no built-in network configuration in images any more.
[01:39] <smoser> yeah, the cloud-images have nothing in /etc/netplan/
[01:46] <cyphermox> err, that's not "no network device"
[01:47] <cyphermox> and in your paste: http://paste.ubuntu.com/25832717/
[01:47] <cyphermox> [    1.848991] e1000 0000:00:03.0 eth0: (PCI:33MHz:32-bit) 52:54:00:12:34:56
[01:47] <cyphermox> [    1.849784] e1000 0000:00:03.0 eth0: Intel(R) PRO/1000 Network Connection
[01:47] <cyphermox> [    1.851505] e1000 0000:00:03.0 ens3: renamed from eth0
[01:47] <cyphermox> despite your line 1 being "xkvm --netdev= ..."
[01:48] <cyphermox> unless you mean something else
[01:48] <smoser> yea, so the --netdev= did the right thing and did not add a device itself, but qemu must add one if you dont have a network device
[01:49] <smoser> and don't add '-nodefaults'
[01:49] <cyphermox> on cloud images it is fair to expect that cloud-init will write your netplan config, I think
[01:49] <smoser> either way, there was no configuration in /ec/ so no blocking and waiting for magical configuration to appear should have been done.
[01:49] <cyphermox> sure
[01:49] <smoser> cyphermox: yeah, your thought process is sane, except it explicitly did *not* write config.
[01:49] <smoser> and when it does, it writes it pre-networking
[01:49] <cyphermox> that's right, you disabled cloud-init
[01:50] <smoser> so no blockign and waiting makes any sense.
[01:50] <cyphermox> blocking and waiting is correct there; that is what you *should* do if there is config, to ensure that the device has had time to come up before you try to send packets over it
[01:51] <smoser> well yeah.
[01:51] <smoser> but there is no config.
[01:51] <smoser> so blockin and waiting for config to appear is kind of pointless.
[01:51] <smoser> or for network devices to appear.
[01:51] <cyphermox> I agree there is a bug in wait-online though, which should not have waiting in your case with cloud-init disabled, because all the devices are unmanaged (since there is no config)
[01:51] <cyphermox> that's a bug in wait-online
[01:51] <cyphermox> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1728181
[01:51] <ubot5> Ubuntu bug 1728181 in systemd (Ubuntu) "systemd-networkd-wait-online waits when devices are unmanaged" [Undecided,New]
[01:51] <smoser> right.
[01:52] <cyphermox> but I don't think booting a cloud image with no metadata provider is something supported
[01:53] <cyphermox> smoser: so, what were you trying to achieve?
[01:54] <smoser> cyphermox: well its actually something we've spent way to much time on
[01:54] <smoser> but that is explicitly required.
[01:55] <smoser> cloud-init should disable itself entirely when not in a cloud
[01:55] <smoser> and it does.
[01:55] <cyphermox> right
[01:55] <cyphermox> and that's working as expected
[01:55] <smoser> but then if you have a network device you wait for 120 seconds for no reason.
[01:55] <smoser> http://paste.ubuntu.com/25833672/
[01:55] <smoser> thanks for pointing out that it got a nic
[01:55] <smoser> the above paste there is the same thing but with no nics at all
[01:55] <smoser> at least then, systmed-networkd-wait-online does the right thing.
[01:55] <cyphermox> ok
[01:57] <cyphermox> well, the real question is: "Is a cloud image booted with no datasource something we should support", and I was told "no", if I understood correctly
[01:57] <cyphermox> so yes, there's a bug in wait-online, and it's one we need to fix anyway, but it seems like you got a different answer than I did to the question above.
[02:00] <smoser> well, i've had actual users ask to build an image that would boot in the cloud, but when booted with no cloud would let them log in.
[02:00] <smoser> they'd put a local user in it with a known password
[02:00] <smoser> then they'd have their image on cloud and local to debug and  can login
[02:01] <smoser> (or even no password but a shared ssh key)
[02:01] <smoser> which makes sense.
[02:01] <cyphermox> yeah, but then they'd have cloud-init running to create the user, no?
[02:02] <cyphermox> the ssh key case we need to ignore since it requires network, in which case you do need to wait-online.
[02:02] <cyphermox> the other one we'll fix once wait-online is fixed (bug above), and I expect we'd SRU that fix
[02:02] <smoser> well, this would be someone created the imag themselfvs.
[02:03] <smoser> i just did this locally
[02:04] <cyphermox> well, it doesn't really matter at this level, that's "just" the wait-online bug
[02:04] <cyphermox> maybe metoo it?
[02:04] <smoser> $ qemu-img create -f qcow2 -b artful-cloud-image.img my.img
[02:04] <smoser> $ sudo ~/bin/backdoor-image my.img -v --user=user1 --password=passw0rd1
[02:04] <smoser> # backdoor image is http://bazaar.launchpad.net/~smoser/+junk/backdoor-image/view/head:/backdoor-image
[02:04] <cyphermox> smoser: don't worry about the process, I frankensteined my own image earlier to put in a root password