Comment 20 for bug 1636912

> However, if there isn't a local seed, then we must search again *once* networking is up.

Fair enough, but you can then of course not use that unit to configure the network. But this "if there isn't a local seed" isn't something you can express as a static condition, hence my thought that it might be better if c-i calls s-n-wait-online if and only if it's necessary. But YMMV.

> This works just fine with 'networking.service'

This did/does not really work "fine" IMHO -- all of our cloud images hang for a long time at boot unless you give them a local data source or disable cloud-init. It also imposes the restriction that you must be online during boot, which is fine for a cloud environment, but rather unfriendly for other scenarios.

> due to the "atomic" nature of ifup where once the oneshot service runs, we can assume that networking is up. However, networkd runs and asynchronously brings up networking; which is fine but we now no longer have a clear checkpoint at which cloud-init can run with networking up but before.

Again -- s-n-wait-online.service is exactly the networkd counterpart of networking.service for ifupdown, that gives you the "network is fully configured" synchronization point. The issue is not that it doesn't exist, but that I think that it's not a good thing to depend on either one.

> we really want something like
> After=networking|networkd-wait-online
> which handles determining if networkd was supposed to run or not

That already exists, it's network-online.target -- whatever "implements" it (ifupdown, networkd, NM) will hook itself into this target. Nothing more, nothing less, so if cloud-init just wants to wait until it's online, then just make it Requires/After=network-online.target instead of Before= it. (But again -- this is a very strong dependency which is very inconvenient anywhere but cloud environments with essentially one virtual ethernet card).

BTW, I'm not sure if it came across -- if you play around with this, please drop systemd-networkd.service's After=dbus.service; that will get rid of the worst dependency cycles, and it's something which we can do in Xenial rather easily (not so easy for devel, that's the part we need to discuss with upstream or decide if we care enough about this feature, but eventually I figure we want to get rid of it either way).