Comment 13 for bug 1636912

> I really want to avoid having different cloud-init in any of xenial/yakkety/zesty.

Me too, and I don't see why this would be conceptually required? 'After=systemd-networkd.service" is appropriate in all releases (as that's what you intend to do), after (!) we drop the After=dbus.service from networkd. Simplifying the "Before=basic.target dbus.socket" to "Before=sysinit.target" is something that should be done in y/z and then cleanly backports to x as well.

> I've used After and Requires; but these are focused on when the units starts
rather than when we can expect networking to be up.

Correct. You can't use network-online.target in early boot, that would be a too strong requirement (as e. g. NetworkManager implements this as well). In early boot there can't ever be a *guarantee* that networking works, so the best that you can do is to wait a little bit if you get a default route, e. g. with /lib/systemd/systemd-networkd-wait-online. Of course in desktop or snappy systems you might never get a connection even in late boot, so there need to be some sensible timeouts.

> oddly though when using the ifupdown 'networking.service'; we don't need to use that target.

Yes, that's a Type=oneshot, as it just calls "ifup -a". So that's more or less equivalent to s-n-wait-online --timeout=30 or After=s-n-wait-online.service. But the latter would block the entire boot process for that long if there is no network (and this *did* hit us in snappy already, like bug 1431836) -- my gut feeling is that this can be handled more gracefully/asynchronously in code.

> networkd bringing up eth0 (virtio) on qemu user-net is taking like 40 seconds... why?

That's certainly unusual, it should only take ~ 5s or so. I suggest filing a separate bug for that with your precise config (my suspicion is that you enabled DHCPv6 or similar and it's waiting/timing out for that, or something similar).