cloud-init team mailing list archive
Mailing list archive
Re: questions as I read - boot phases
On 11/01/2017 19:55, Michael Felt wrote:
So, there are few terms that are confusing:
Shortening this - removing AIX specific stuff (that is my worry, not yours)
* generator: what is a generator? What is cloud-init.target? (I
suspect a systemd construct).
* local: in sysv terms this starts
From the docs:
"If this is an instance’s first boot, then the selected network
configuration is rendered. This includes clearing of all previous
(stale) configuration including persistent device naming with old mac
I read this to be:
a) remove aka forget previous settings/state
b) use info from data source to (re-)configure devices - especially when
'static' definitions are involved versus 'device auto-settings (e.g., dhcp)
Block - or again, per my comments above forget (and DHCP - bring a
device down, "forget", enable device again)
This stage must block network bring-up or any stale configuration
might already have been applied.
That could have negative effects such as DHCP hooks or broadcast of an
old hostname. It would also put the system in an odd state to recover
from as it may then have to restart network devices."
Per "docs" on "network" - it seems the goal is to end with (all) devices
re-configured and active.
Again, my uncertainity - are all devices re-configured and active, or
only only the network - AND - I should read the 'name' of this pahse to
mean 'network' is done, now we do the rest.
So, "when does /var/lib/cloud" get copied?
* *runs*: After local stage and configured networking is up.
From this bit of documentation - is this what starts the "init" system
(sysvinit, upstart, udev, systemd, ???)?
* *blocks*: As much of remaining boot as possible.
* *modules*: |init_modules|
"personally" I would have had "disk_setup" and "(local) mounts" in
*local* and "(remote) mounts" in network
docs say: |
|This stage runs the |disk_setup| and |mounts| modules which may
Is this "every" boot, or only "firstboot"? (I read in an example that
bootcmd is 'runonce')
So, except for the 'bootcmd' thre is probably nothing to do here (for
AIX) as this has all be done during "phase 2" of /sbin/rc.boot
* again, in cloud-init terms: how to distinguish when something is
every-boot, versus first-boot (ah yes, thinking further, the variables:
This stage runs config modules only. Modules that do not really have
an effect on other stages of boot are run here.
Anyway - the labels seem (now) to be a bit arbitrary - or maybe 'ideal'
for systemd. I'll "live" with them - while my gut says 'historical'
and/or system(distro) dependent (aka not generic).
This stage runs as late in boot as possible. Any scripts that a user
is accustomed to running after logging into a system should run
correctly here. Things that run here include
* package installations
* configuration management plugins (puppet, chef, salt-minion)
* user-scripts (including |runcmd|).