On Fri, Oct 28, 2016 at 1:02 PM, Martin Pitt <email address hidden> wrote:
> > 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.
Of course we can. We need to cycle the network though.
> 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.
>
Right, though it's not clear to me that we can express this in unit terms.
It may have to be done internally; That is, it's possible that in
cloud-init "net"
mode we need to block ourselves, until networking is-up.
>
>
> > 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.
This is by-design. cloud-init is *interposing* itself on purpose.
> 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.
>
No, you need provide a datasource, or indicate (via boot params) that
you're not
interested in cloud-init running.
It's certainly true that if someone just qemu-system-x86 -hda cloud.img
that it's going
to hang. But folks are explicitly booting a *cloud* image without a cloud.
We handle this fine with uvt-kvm which provides a nocloud-net seed when
booting.
> > 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.
>
It is, but it's a separate unit "networking" == "networkd" +
"networkd-wait-online"
However, netplan generator only emits the "systemd-networkd" target wants,
so
if we use After=systemd-networkd-wait-online; that's never run since
nothing wants it.
If we add it explicitly, then it runs even when networkd doesn't
>
> > 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).
>
It may be that network-online.target is the right place. Scott had some
reason
for not using that explicitly before; I expect some details from him.
It's no more inconvenient than cloud-init has ever been for users not
providing
a data-source, or booting with cloud-init disabled.
>
> 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).
>
I did play with it, but the networkd in xenial blocks for some non-trivial
amount of time (10s of seconds)
if dbus.service is not up.
On Fri, Oct 28, 2016 at 1:02 PM, Martin Pitt <email address hidden> wrote:
> > 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.
Of course we can. We need to cycle the network though.
> 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.
>
Right, though it's not clear to me that we can express this in unit terms.
It may have to be done internally; That is, it's possible that in
cloud-init "net"
mode we need to block ourselves, until networking is-up.
> service'
>
> > This works just fine with 'networking.
>
> 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.
This is by-design. cloud-init is *interposing* itself on purpose.
> 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.
>
No, you need provide a datasource, or indicate (via boot params) that
you're not
interested in cloud-init running.
It's certainly true that if someone just qemu-system-x86 -hda cloud.img
that it's going
to hang. But folks are explicitly booting a *cloud* image without a cloud.
We handle this fine with uvt-kvm which provides a nocloud-net seed when
booting.
> > due to the "atomic" nature of ifup where once the oneshot service online. service is exactly the networkd counterpart of
> 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-
> 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.
>
It is, but it's a separate unit "networking" == "networkd" + wait-online" networkd- wait-online; that's never run since
"networkd-
However, netplan generator only emits the "systemd-networkd" target wants,
so
if we use After=systemd-
nothing wants it.
If we add it explicitly, then it runs even when networkd doesn't
> g|networkd- wait-online online. target -- whatever "implements" After=network- online. target instead
> > we really want something like
> > After=networkin
> > which handles determining if networkd was supposed to run or not
>
> That already exists, it's network-
> 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/
> 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).
>
It may be that network- online. target is the right place. Scott had some
reason
for not using that explicitly before; I expect some details from him.
It's no more inconvenient than cloud-init has ever been for users not
providing
a data-source, or booting with cloud-init disabled.
> networkd. service' s After=dbus.service; that will get
> BTW, I'm not sure if it came across -- if you play around with this,
> please drop systemd-
> 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).
>
I did play with it, but the networkd in xenial blocks for some non-trivial
amount of time (10s of seconds)
if dbus.service is not up.
> /bugs.launchpad .net/bugs/ 1636912 /bugs.launchpad .net/systemd/ +bug/1636912/ +subscriptions
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> systemd-networkd runs too late for cloud-init.service (net)
>
> To manage notifications about this bug go to:
> https:/
>