/srv/irclogs.ubuntu.com/2017/10/28/#cloud-init.txt

cyphermoxsmoser: 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:09
smosercyphermox: well i had actually attached *no* network devices. which clearly should mean "all networking that will be configured is configured".01:28
cyphermoxsmoser: I saw your command-line, but I don't think it behaved quite as expected01:32
cyphermoxor I don't understand what the kernel does, because it tries to rename an ens3 or eth0 that isn't there.01:33
smoserwhat command line?01:37
smoserthere is no network device.01:37
smoseri blieve there is no built-in network configuration in images any more.01:38
smoseryeah, the cloud-images have nothing in /etc/netplan/01:39
cyphermoxerr, that's not "no network device"01:46
cyphermoxand 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:5601:47
cyphermox[    1.849784] e1000 0000:00:03.0 eth0: Intel(R) PRO/1000 Network Connection01:47
cyphermox[    1.851505] e1000 0000:00:03.0 ens3: renamed from eth001:47
cyphermoxdespite your line 1 being "xkvm --netdev= ..."01:47
cyphermoxunless you mean something else01:48
smoseryea, 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 device01:48
smoserand don't add '-nodefaults'01:49
cyphermoxon cloud images it is fair to expect that cloud-init will write your netplan config, I think01:49
smosereither way, there was no configuration in /ec/ so no blocking and waiting for magical configuration to appear should have been done.01:49
cyphermoxsure01:49
smosercyphermox: yeah, your thought process is sane, except it explicitly did *not* write config.01:49
smoserand when it does, it writes it pre-networking01:49
cyphermoxthat's right, you disabled cloud-init01:49
smoserso no blockign and waiting makes any sense.01:50
cyphermoxblocking 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 it01:50
smoserwell yeah.01:51
smoserbut there is no config.01:51
smoserso blockin and waiting for config to appear is kind of pointless.01:51
smoseror for network devices to appear.01:51
cyphermoxI 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
cyphermoxthat's a bug in wait-online01:51
cyphermoxhttps://bugs.launchpad.net/ubuntu/+source/systemd/+bug/172818101:51
ubot5Ubuntu bug 1728181 in systemd (Ubuntu) "systemd-networkd-wait-online waits when devices are unmanaged" [Undecided,New]01:51
smoserright.01:51
cyphermoxbut I don't think booting a cloud image with no metadata provider is something supported01:52
cyphermoxsmoser: so, what were you trying to achieve?01:53
smosercyphermox: well its actually something we've spent way to much time on01:54
smoserbut that is explicitly required.01:54
smosercloud-init should disable itself entirely when not in a cloud01:55
smoserand it does.01:55
cyphermoxright01:55
cyphermoxand that's working as expected01:55
smoserbut then if you have a network device you wait for 120 seconds for no reason.01:55
smoserhttp://paste.ubuntu.com/25833672/01:55
smoserthanks for pointing out that it got a nic01:55
smoserthe above paste there is the same thing but with no nics at all01:55
smoserat least then, systmed-networkd-wait-online does the right thing.01:55
cyphermoxok01:55
cyphermoxwell, the real question is: "Is a cloud image booted with no datasource something we should support", and I was told "no", if I understood correctly01:57
cyphermoxso 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.01:57
smoserwell, 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
smoserthey'd put a local user in it with a known password02:00
smoserthen they'd have their image on cloud and local to debug and  can login02:00
smoser(or even no password but a shared ssh key)02:01
smoserwhich makes sense.02:01
cyphermoxyeah, but then they'd have cloud-init running to create the user, no?02:01
cyphermoxthe ssh key case we need to ignore since it requires network, in which case you do need to wait-online.02:02
cyphermoxthe other one we'll fix once wait-online is fixed (bug above), and I expect we'd SRU that fix02:02
smoserwell, this would be someone created the imag themselfvs.02:02
smoseri just did this locally02:03
cyphermoxwell, it doesn't really matter at this level, that's "just" the wait-online bug02:04
cyphermoxmaybe metoo it?02:04
smoser$ qemu-img create -f qcow2 -b artful-cloud-image.img my.img02:04
smoser$ sudo ~/bin/backdoor-image my.img -v --user=user1 --password=passw0rd102:04
smoser# backdoor image is http://bazaar.launchpad.net/~smoser/+junk/backdoor-image/view/head:/backdoor-image02:04
cyphermoxsmoser: don't worry about the process, I frankensteined my own image earlier to put in a root password02:04

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!