cloud-init team mailing list archive

[Bean Taxi <beantaxi@xxxxxxxxx>]

Hi Daniel,

Thanks for your excellent answer.

For my own edification, I'd be curious as to why once-boot-instance was
chosen back in 2011. Probably there was an instructive reason that I'm
unaware of but I'd be interested to know.

Either way, I take your point that changing it at this point would require
a pretty high bar. cloud-init has a truly massive user base and who knows
who an execution order change would break, and how.

Changing the order in /etc/cloud/cloud.cfg -- if that indeed would be an
effective remedy -- would not be great for my use case. I'm trying for a
"write a per-instance and per-boot script, then deploy anywhere and don't
worry about it" workflow, and if every host system would need an edit, that
could be a problem. If there's a way of overriding execution/module order
that can be provided by the user, eg through user data, that would be
significantly better.

Worst case though, it sounds like I could simply live with the existing
characteristics of cloud-init, namely that anything in per-boot that
requires per-instance will not run successfully, and in fact would need to
happen at the end of per instance to make sure it happens on startup.
That's not the end of the world, and it's what would be required to use
cloud-init in any case.

Happy for any thoughts you might have on the above. And in any case thanks
again for the thoughtful and detailed response.

B

On Tue, Sep 8, 2020 at 9:54 AM Daniel Watkins <daniel.watkins@xxxxxxxxxxxxx>
wrote:

> On Fri, Sep 04, 2020 at 01:23:32PM -0500, Bean Taxi wrote:
> > The latter - executing in order of decreasing frequency, ie
> > once-instance-boot, strikes me as more logical, and it's better for my
> use
> > case (so perhaps Im biased). But decisions tend to have reasons and so
> > perhaps once-boot-instance is intentional for reasons not immediately
> > obvious to me.
>
> It has been this way since 2011.
>
> https://github.com/canonical/cloud-init/commit/516e378f0e79d127baeac8c6418efc504d3b713e
> introduced the lines that are still in `config/cloud.cfg.tmpl`.  That
> was a refactor of an upstart service that previously handled user
> scripts; execution frequency was introduced into that script in
>
> https://github.com/canonical/cloud-init/commit/be61755c7723790b68f30b8acaf1ce8ba2410dd4
> .
>
> Neither of these commits have any specific reasoning around the order;
> Scott, perhaps you can remember some more detail from a decade ago?
>
> Regardless of original intent, given how long it has been this way, I
> don't know if we can safely modify the default configuration we ship,
> lest we break configurations that rely on the current ordering.
>
> > If so, is altering module order a normal action? Seems a bit low-level
> and
> > esoteric to me but Im new at this.
>
> It is unusual to need to modify the order: for most cloud-configs, the
> order of the modules doesn't matter much (because people are specifying
> a small set of options, with no dependencies between them) and the
> default order works for the majority of remaining cloud-configs.  So I
> wouldn't call it a "normal" action, but that doesn't mean that it
> shouldn't ever be done.
>
> When people modify the module order, it can make it harder for us to
> provide support: in some cases, people will hit "bugs" which only exist
> if you modify the default module order (or remove modules from it).
> While we will certainly accept fixes for such issues, there are some
> cases where we do have to tell users that they simply should not be
> doing what they're doing.
>
> All this said, I think modifying your module order in the way you're
> proposing *is* safe, given that you are building images for a specific
> use case.  cloud-init doesn't do anything in the scripts-per-* modules
> without user-provided configuration so there aren't any implicit
> dependencies between them for you to break by reordering them, and you
> don't have to worry about other users writing cloud-config which assumes
> the ordering that you're changing.
>
>
> Cheers,
>
> Dan
>