← Back to team overview

cloud-init team mailing list archive

Re: questions as I read - boot phases


On 23/01/2017 20:20, Ryan Harper wrote:
On Sun, Jan 15, 2017 at 12:46 PM, Michael Felt<michael@xxxxxxxxxxxxx>

On 14/01/2017 15:35, Michael Felt wrote:
Looks the (sysvinit) scripts give a 'one-line' description that sets focus
(in a way I can understand, sometimes verbose is just confusing)

Short-Description *
cloud-config:# Short-Description: The config cloud-init job
cloud-final:# Short-Description: The final cloud-init job
cloud-init:# Short-Description: The initial cloud-init job (net and fs
cloud-init-local:# Short-Description: The initial cloud-init job (local fs

So, with above - still do not know what 'generator' is,

The generator refers to a systemd-generator which is a short program or
script which is called very early during boot by systemd itself;  a
generator is responsible for determining if a unit (one or more init
OK. Lets call it a script. It is possible that perhaps that it compares with /etc/rc.d/rc - which is a script
that gets called with one argument: the run-level.

This is called, in AIX, from /etc/inittab - one line gets called (out of several) - based on the run-level (default is 2)
the system is "initiating", excerpt:

l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

should run, and if so when (sort of like run-levels in sysv symlinking an
initscript into a specific runlevel dir)
Yes, these days it is popular to store the files - without any {S|K}XX prefixes (e.g., S99program is normally paired with K00program for (S)tart last (99) during startup and stop (Kill) first (00). These are the programs that are either hard or soft-linked into their
respective /etc/rc.d/rc${runlevel}.d/ directories

In cloud-init's case, the generator examines the kernel command line
There are no ways (that I am aware of) to send the kernel a modified/additional "command-line" argument during boot.
and a
few files on the filesystem to see if cloud-init is to be disabled or
enabled;  the default is to be enabled.
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..."

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)

It might be that we would need to use some of the more common rc script
checks for a file, and if not present or a specific value set, then each of
those init-scripts exit without invoking cloud-init.

not do I know when /var/lib/cloud gets "copied" - but I do understand -
better - the difference between cloud-init-local and cloud-init

/var/lib/cloud doesn't get copied; it does get populated during boot;
Thx. I shall have to read the comments/content of ALL the .py code to see when and what they are writing. Maybe you can give a hint: I would hope there is a cloud-init module they all call.
example, the instances/ directory is populated with the various
instance-id values that have been discovered;
I expect that in some environments - a "host" is running multiple "instances" in a common environment - at least if I understand 'instance' correctly. In the most common AIX setting - AIX would be running it it's own - firmware isolated VM (aka LPAR aka partition)
and I would expect it to contain only one "instances/instance-id" directory.
typically each time you boot
an instance, either it has an id embedded (A nocloud datasource would
provide an id)
I am still trying to understand what a NOCLOUD datasource is - but I am sure my initial idea was wrong (my bad, I was thinking "NODATASOURCE" - where I should have read it literally - A DATASOURCE but NOt CLOUD management. AND - my additional thought is that cloud-init is intended as the mechanism that ALWAYS re-configures the system according to information in the DATASOURCE - and stores the 'results' in /var/lib/cloud/instances/${my-instanceid}/
or if it's in a cloud, the cloud provides an instance-id in its metadata
service;  this allows an image to be booted somewhere else and cloud-init
will known that it needs to run certain stages/config modules again since
the image isn't booting on the same instance-id;
I am thinking - something I see missing for the current AIX port is a way to determine whether, new, reboot in same location, or reboot in new location aka "Host" (in (IBM-terms "Frame" compares 1-to-1 with the OpenStack term: "Host"))
contrast with
rebooting an instance with the same id, cloud-init can skip some
stages/config as they are only performed once per-instance (ssh host
keygen, for example).
Again - I am wondering what you are considering. I can only come up with IP-address that needs a change because I have changed HOST and the old IP-Address is no longer suitable. In a DHCP environment - easy - because I never cared what my IP address was. I will need a way to tell the DNS server my new IP address. And, perhaps this is also already 'normal' boot, DHCP - get address, DNS_update - make sure DNS knows my hostname is a CNAME for X.Y.Z.me, etc..

I have seen differences in the different distributions of Linux, and where, for example - device information is stored. In AIX this not (usually) (usually) stored in a file (i.e., it could be but noone I know has since 1994-1995). Instead, known devices are registered in the ODM and an entry is created - if needed in /dev. Device attribute settings are also in the ODM.

This is actually, where it gets complicated between AIX and cloud-init boot phases.

You speak of different "moments" or "phases" in the boot process. From above, I hope that I understand the 'generator' idea.

* I now take it to mean: kernel and ramdisk filesystem are active, "device" discovery has not yet happened. Actually, since you also look at "files" the "rootvg" filesystem is already mounted. Hence, some device "discovery" as already occurred. With the exception of the devices needed to mount the root volume group/volume - no (other) devices have been "activated" aka "configured".

* Is this "proposition" of how far system initialization has come when generator is called? And the "finish" is that some or all of the remaining parts
of cloud-init is scheduled.

Many thanks for your feedback!



Follow ups