* In current xenial, cloud-init runs in late boot, so there is no principal ordering problem between cloud-init and networkd, other than that cloud-init.service should declare After=systemd-networkd.service similar to what it does for ifupdown (After=networking.service).
* Thus this would not be a blocker for Ubuntu Core 16 right now, and merely adding that After= should suffice for the moment.
* This *is* an issue for 16.10/zesty as cloud-init.service runs in early boot and dbus/networkd can't.
* This *will become* an issue for 16.04 as these cloud-init changes are meant to be backported soon. Will that happen for the Ubuntu Core 16 GA in a few days already? I. e. is this something which we need to crowbar in ASAP, or do we have some time to figure out a proper solution how to start networkd first, and dbus later on?
So did I understand this right:
* In current xenial, cloud-init runs in late boot, so there is no principal ordering problem between cloud-init and networkd, other than that cloud-init.service should declare After=systemd- networkd. service similar to what it does for ifupdown (After= networking. service) .
* Thus this would not be a blocker for Ubuntu Core 16 right now, and merely adding that After= should suffice for the moment.
* This *is* an issue for 16.10/zesty as cloud-init.service runs in early boot and dbus/networkd can't.
* This *will become* an issue for 16.04 as these cloud-init changes are meant to be backported soon. Will that happen for the Ubuntu Core 16 GA in a few days already? I. e. is this something which we need to crowbar in ASAP, or do we have some time to figure out a proper solution how to start networkd first, and dbus later on?