cloud-init team mailing list archive

[Ryan Harper <ryan.harper@xxxxxxxxxxxxx>]

On Tue, Jan 24, 2017 at 1:33 AM, Michael Felt <michael@xxxxxxxxxxxxx> wrote:

> On 23/01/2017 20:20, Ryan Harper wrote:
>
> On Sun, Jan 15, 2017 at 12:46 PM, Michael Felt <michael@xxxxxxxxxxxxx> <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.
>

Interesting, any documentation or pointers to AIX bootloaders?  This isn't
strictly required, but it's sometimes useful to be able
to disable cloud-init temporarily.


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

That's correct; more specifically, the various stage scripts don't
themselves check for things like the above file directly; they rely on the
generator
to enable or disable them as needed.

For /etc/intitab, it's likely that you'll want to add such a check (which
can rely on the same file path for consistency) directly to the start
of each stage script.


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

Close, systemd builds a dependency graph and executes all units in
parallel, converging the parallelism at certain choke points, called
targets.
The design is to enable faster boot by expressing dependencies directly
between units and targets and running all units in parallel.


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

If you look in the source tree, you can see the systemd unit files, which
are simple invokations of cloud-init itself

systemd/cloud-init-local.service

Runs:  /usr/bin/cloud-init init --local

The cloud-init stage sequence looks like this:

/usr/bin/cloud-init init --local
/usr/bin/cloud-init init
/usr/bin/cloud-init modules --mode=config
/usr/bin/cloud-init modules --mode=final




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

Host here refers to the booting instance, so each LPAR would be a host
which would only run one instance.  Now, if you snapshotted that LPAR's
filesystem and started a new LPAR using the same filesystem snapshot, you
would want it to have a new instance-id so that this duplicate LPAR did not
use the same SSHD keys and other generated data that should be unique
per-instance.


>
> 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}/
>

Yep!


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

cryptographic keys for the host (sshd is the primary example); DHCP clients
write out lease files which include instance MAC address and any of the
configuration modules may have recorded hostname or other information which
shouldn't be duplicated.


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

For systemd replaces 'init', so generically speaking, the kernel and
ramdisk have been loaded, the ramdisk has run far enough to mount the root
device in read-only mode and invokes '/sbin/init'  which is systemd.  The
generators run very early to determine what sets of scripts to run based on
whatever criteria a generator looks for.

Sometime later during the boot, the 4 stages of cloud-init are called as
long as the generator did not disable cloud-init.

Ryan