Comment 18 for bug 1636912

On Thu, Oct 27, 2016 at 3:57 PM, Martin Pitt <email address hidden> wrote:

> > cloud-init expects networking to be up, like 'networking.service'
> before it runs..
>
>
> I think it needs to make up its mind -- why does it want to run
> Before=network-online.target then? I thought the idea was that cloud-init
> is able to *provide* a network configuration (through the YAML). It seems
> to me that this might have to be split into two parts then -- one that can
> provide network config which runs early and does not require networking,
> and one that can use the network to configure other bits?
>

we have to do both.

In the case that we have a local config which provides networking
configuration, we can emit it, and then we want to "bring it up"

In other cases, we may need to bring up fallback networking (ie, dhcp on
eth0) to look for a metadata service on the network
which also may provide network configuration (which we writeout) and then
want to "bring it up"

>
> > So why shouldn't we use networkd-wait-online ?
>
> You can use the program. I said that it might not be the best idea to
> use After=s-n-wait-online.service, as that would block the entire cloud-
> init.service and with it the entire boot (as cloud-init.service has very
> strong dependencies) if there is no network available.
>

cloud-init.service *requires* network; it's designed to block until then
otherwise
you just timeout trying to reach network endpoints like Openstack metadata
service.

The "hang" in UbuntuCore was primarily related to *not* providing a nocloud
seed
in the image; when it was booted without a seed and not disabled, it goes
an *looks* for a seed, first local, then over the net.

>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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
>