Comment 22 for bug 1636912

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 1636912] Re: systemd-networkd runs too late for cloud-init.service (net)

On Fri, Oct 28, 2016 at 06:02:29PM -0000, Martin Pitt wrote:
> > However, if there isn't a local seed, then we must search again *once*
> networking is up.

> 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.

Yes, it's not a static condition; and even if it *were*, cloud-init should
apply sensible timeouts in the event that no network source is available.
So s-n-wait-online is still the better answer.

> > 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.

That is the image working as designed, when booted in an environment it's
not designed for.

> 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.

cloud-init does not *require* you to be online. It *requires* you to
provide a data source; as you've already pointed out, it can be a local disk
or it can be a network source. Sometimes you have a disk source, sometimes
you have a network source; this is not a design decision of cloud-init, it's
a function of the *cloud environment* where you're booting the image, and
it's out of the scope of this bug to redesign cloud-init to be something
other than it is - a tool for provisioning generic images when booting
noninteractively in a cloud.