Comment 9 for bug 1636912

On Thu, Oct 27, 2016 at 8:43 AM, Ryan Harper <email address hidden>
wrote:

>
>
> On Thu, Oct 27, 2016 at 5:59 AM, Martin Pitt <email address hidden>
> wrote:
>
>> 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).
>>
>>
I'm playing with this now, and we've got some more ordering to do.

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.

networkd runs but it takes a few seconds to get DHCP responses and have
the interfaces come up. What I'm seeing is that systemd runs networkd, this
then allows cloud-init.service to run; which it then checks on the network
interfaces
and finds that eth0 isn't up yet, several seconds later eth0 does come up
but not
before cloud-init.service runs.

There is a network-online.target, which I think we'd want to say
cloud-init.service runs
After that; oddly though when using the ifupdown 'networking.service'; we
don't need
to use that target. and cloud-init.service explicitly runs
Before=network-online.target

That seems wrong since cloud-init.service may scan for network metadata
services.
If I remove that line, I'll see how that affects both the ifupdown and
networkd path.

Ryan