← Back to team overview

cloud-init team mailing list archive

Re: Script execution order: why (once, boot, instance) instead of (once, instance, boot)?


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

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.



Attachment: signature.asc
Description: PGP signature

Follow ups