cloud-init team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

On Tue, 24 Jan 2017, Ryan Harper wrote:

> On Tue, Jan 24, 2017 at 1:33 AM, Michael Felt <michael@xxxxxxxxxxxxx> wrote:
>
> > So, if I now, more clearly understand the basics of 'generator' and
> > http://cloudinit.readthedocs.io/en/latest/topics/boot.html
> > I take this to mean cloud-init is always 'enabled' because the file /etc/cloud/cloud-init.disabled
> > is only "valid"
> > when (quote from docs) "When booting under systemd..."
> >
>
> That's correct; more specifically, the various stage scripts don't
> themselves check for things like the above file directly; they rely on the
> generator
> to enable or disable them as needed.

They don't now, but I don't think I'm opposed to having the sysvinit
scripts do such checks.  The real value of the generator in systemd, is
that if it determines that cloud-init does not need to run, then there is
no change in the systemd boot ordering to accommodate cloud-init.

Since there isn't really a boot-time analog in sysvinit (to my knowledge),
I'm fine to have the scripts do nothing if cloud-init is disabled via the
mechanisms that would disable it in the generator.

> For /etc/intitab, it's likely that you'll want to add such a check (which
> can rely on the same file path for consistency) directly to the start
> of each stage script.
>
>
> > I don't think there is a direct equivalent in sysvinit; rather at
> > install-time cloud-init packaging would have setup the symlinks in various
> > rc.X directories (at least on Linux)
> >
> > Ah - "the plot thickens" - systemd 'generator' - generates the
> > 'sysvinit-like' list of programs to run (i.e., the loop within /etc/rc.d/rc
> > that finds and sorts all the scripts with 'S' as first letter, and then
> > executes these scripts sequentially)
> >
>