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