On Thu, Oct 27, 2016 at 2:50 PM, Martin Pitt <email address hidden> wrote:
> > oddly though when using the ifupdown 'networking.service'; we don't
> need to use that target.
>
> Yes, that's a Type=oneshot, as it just calls "ifup -a". So that's more
> or less equivalent to s-n-wait-online --timeout=30 or After=s-n-wait-
> online.service. But the latter would block the entire boot process for
> that long if there is no network (and this *did* hit us in snappy
> already, like bug 1431836) -- my gut feeling is that this can be handled
> more gracefully/asynchronously in code.
>
Where though? cloud-init expects networking to be up, like
'networking.service'
before it runs.. So why shouldn't we use networkd-wait-online ?
Additionally, cloud-init needs to wait for networking to be up, whether the
system
is using ifupdown/networking.service or netplan/networkd ... Adding After=
for both of these
appears to be problematic; we really want something like
After=networking|networkd-wait-online
which handles determining if networkd was supposed to run or not
Maybe a Conditional After would be nice here; we could see if networkd was
expected to start
It's possible that this isn't an issue outside of Ubuntu Core 16.
For Xenial cloud-images, we don't yet have networkd/resolved/ and netplan
to replace ifupdown setup
For Y+ cloud-images, we can moved to that if we want since all of the parts
are there too
For UC16 on Xenial, it *does* have networkd/netplan and expects to use that
by default; however it
currently comes in with a dep on ifupdown which could be dropped if
cloud-init has enough support
for network yaml v2/netplan for fallback networking (though the UC16 image
has a built-in network
config like the older cloud-images did).
On Thu, Oct 27, 2016 at 2:50 PM, Martin Pitt <email address hidden> wrote:
> > oddly though when using the ifupdown 'networking. service' ; we don't asynchronously in code.
> need to use that target.
>
> Yes, that's a Type=oneshot, as it just calls "ifup -a". So that's more
> or less equivalent to s-n-wait-online --timeout=30 or After=s-n-wait-
> online.service. But the latter would block the entire boot process for
> that long if there is no network (and this *did* hit us in snappy
> already, like bug 1431836) -- my gut feeling is that this can be handled
> more gracefully/
>
Where though? cloud-init expects networking to be up, like service' wait-online ?
'networking.
before it runs.. So why shouldn't we use networkd-
Additionally, cloud-init needs to wait for networking to be up, whether the networking. service or netplan/networkd ... Adding After=
system
is using ifupdown/
for both of these
appears to be problematic; we really want something like
After=networkin g|networkd- wait-online
which handles determining if networkd was supposed to run or not
Maybe a Conditional After would be nice here; we could see if networkd was
expected to start
It's possible that this isn't an issue outside of Ubuntu Core 16.
For Xenial cloud-images, we don't yet have networkd/resolved/ and netplan
to replace ifupdown setup
For Y+ cloud-images, we can moved to that if we want since all of the parts
are there too
For UC16 on Xenial, it *does* have networkd/netplan and expects to use that
by default; however it
currently comes in with a dep on ifupdown which could be dropped if
cloud-init has enough support
for network yaml v2/netplan for fallback networking (though the UC16 image
has a built-in network
config like the older cloud-images did).