cloud-init team mailing list archive

[Michael Felt <michael@xxxxxxxxxxxxx>]

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)
> Reading https://cloudinit.readthedocs.io/en/latest/topics/boot.html
>
> * generator: what is a generator? What is cloud-init.target? (I 
> suspect a systemd construct).
>
> * local: in sysv terms this starts 
> /etc/rc.d/rcX.d/SXX/cloud-init-local start
Snip
> 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 
> addresses.
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)
> This stage must block network bring-up or any stale configuration 
> might already have been applied.
Block - or again, per my comments above forget (and DHCP - bring a 
device down, "forget", enable device again)
> 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.
> So, "when does /var/lib/cloud" get copied?
>
> * network
>
> docs say:
>
>  * *runs*: After local stage and configured networking is up.
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.
>  * *blocks*: As much of remaining boot as possible.
>  * *modules*: |init_modules|
From this bit of documentation - is this what starts the "init" system 
(sysvinit, upstart, udev, systemd, ???)?
> docs say: |
> |This stage runs the |disk_setup| and |mounts| modules which may 
> partition
"personally" I would have had "disk_setup" and "(local) mounts" in 
*local* and "(remote) mounts" in network
> 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
Is this "every" boot, or only "firstboot"? (I read in an example that 
bootcmd is 'runonce')
> * config
>
> docs: |
> This stage runs config modules only. Modules that do not really have 
> an effect on other stages of boot are run here.
* again, in cloud-init terms: how to distinguish when something is 
every-boot, versus first-boot (ah yes, thinking further, the variables: 
RUNONCE, etc)
> * final
> docs:|
> 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|).
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).

> Michael