cloud-init team mailing list archive

[Ryan Harper <ryan.harper@xxxxxxxxxxxxx>]

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)
should run, and if so when (sort of like run-levels in sysv symlinking an
initscript into a specific runlevel dir).

In cloud-init's case, the generator examines the kernel command line and a
few files on the filesystem to see if cloud-init is to be disabled or
enabled;  the default is to be enabled.

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)

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;  for
example, the instances/ directory is populated with the various
instance-id values that have been discovered; typically each time you boot
an instance, either it has an id embedded (A nocloud datasource would
provide an id)
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;  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).

Ryan








>
> 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
>
>
>
>
>
>
>
>
> --
> Mailing list: https://launchpad.net/~cloud-init
> Post to     : cloud-init@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~cloud-init
> More help   : https://help.launchpad.net/ListHelp
>
>