cloud-init team mailing list archive

[Michael Felt <michael@xxxxxxxxxxxxx>]

I know AIX. AIX does not use systemd (and internally it seems to be 
called sysv (aka sys5) the "ancient" AT&T "new" method rather than 
/etc/inittab. (And AIX, of course uses the UNIXv6/UNIXv7/'bsd' inittab 
approach.

So, there are few terms that are confusing:

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

Saving me the hassle of reading all the code - what does this actually 
do. From the doc I conclude it is after the "root volume group has been 
mounted" - in AIX terms it is rather late in the game (e.g., 
/etc/rc.tcpip has already run). If it needs to be earlier then "I need 
to be thinking about changes to /sbin/rc.boot" because this is when AIX 
is still very early in the boot process (aka AIX boot phase 2, boot 
phase 3 is when programs start getting called via /etc/inittab entries 
(that - towards the end, call "/etc/rc.d/rc 2" (default run-level is 2).

I have never read any (official) documentation - but apparantly, to get 
it to work at all with AIX (and cloud-init-0.7.5) a configuration 
setting was added (there are two - related, but very different sys0 
attributes: clouddev and ghostdev)

I am thinking "maybe" it is better to have cloud-init-local closer to 
AIX phase 2, rather than some magic in the background changing things as 
some vague time. All I can read is:

michael@x071:[/home/michael]lsattr -El sys0 | grep dev
clouddev        0                                    Recreate ODM 
devices on next boot                 True
ghostdev        0                                    Recreate devices in 
ODM on system change          True

Rumors say: ghostdev is to support the now defunct "Activation Engine" 
and clouddev is to support "cloud-init". I have, obviously, not looked 
hard enough for the documentation of these variables.

So much for my grief re: AIX documentation - my core-question is: Is 
this when the /var/lib/cloud area gets populated? And I am trying to 
(guess) find how the system knows on subsequent boots that the 
"first-boot" datasource - is no more. (Or is it considered "good 
practice" to modify /etc/cloud/cloud.cfg and add 'network: {config: 
disabled}'

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.

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

As we are in phase 3 - either the 'clouddev' entry above has stopped 
them from being activated (better, unconfigured then rediscovered) - 
then the 'rendering' can occur unhindered.

So, "when does /var/lib/cloud" get copied?

* network

docs say:

 * *runs*: After local stage and configured networking is up.
 * *blocks*: As much of remaining boot as possible.
 * *modules*: |init_modules|

|Thus, I conclude 'local' brings network up (while I was thinking - 
originally - local meant 'without IP support" ('local' DataOcean 
datasource permits (I read needs) network support even before networking 
is 'rendered'.

docs say: |
|This stage runs the |disk_setup| and |mounts| modules which may partition

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

* config

docs: |
This stage runs config modules only. Modules that do not really have an 
effect on other stages of boot are run here.

|This is basically - what AIX boot phase 3 is: If this was NIM - I would 
call it "firstboot" scripts.
Question: this is the cc_* "stuff" in the ./config directory?

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

|Again - lucky me: not really any different from the "config" stage, as 
far as the AIX boot process is concerned. For now - (on AIX) it is the 
phase that calls "runcmd", and will call 'reboot' (I expect it is this 
part that does that) when requested.

Anyway - thank you for your attention. I would appreciate feedback - 
where I got it wrong.
Once this flow is clear to me I will be better able to organize my effort.

Michael
|