On Thu, Oct 27, 2016 at 8:43 AM, Ryan Harper <ryan.har...@canonical.com> wrote:
> > > On Thu, Oct 27, 2016 at 5:59 AM, Martin Pitt <martin.p...@ubuntu.com> > 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 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1636912 Title: systemd-networkd runs too late for cloud-init.service (net) To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1636912/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs