cloud-init team mailing list archive

[Michael Felt <michael@xxxxxxxxxxxxx>]

On 23/01/2017 20:20, Ryan Harper wrote:
> On Sun, Jan 15, 2017 at 12:46 PM, Michael Felt<michael@xxxxxxxxxxxxx>
> wrote:
>
> > 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)
> >
> > michael@x071:[/data/prj/aixtools/cloud-init/aix-port/init/sysvinit/aix]grep
> > 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
> > contingent)
> > cloud-init-local:# Short-Description: The initial cloud-init job (local fs
> > contingent)
> >
> > 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
> scripts)
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.
>    for
> 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!

Michael
> Ryan