cloud-init-dev team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

On Wed, 9 Nov 2016, Ryan Harper wrote:

>
>
> Diff comments:
>
> > diff --git a/doc/rtd/topics/boot.rst b/doc/rtd/topics/boot.rst
>
> Either lowercase Generator, or Upper case the rest?

Upper cased in both places (title and summary).
>
> > + * A file exists: ``/etc/cloud/cloud-init.disabled``
> > + * The kernel command line as fond in /proc/cmdline contains ``cloud-init=disabled``.
> > +   When running in a container, the kernel command line is not honored, but
> > +   cloud-init will read an environment variable named ``KERNEL_CMDLINE`` in
> > +   its place.
> > +
>
> Should we include what the equivalent sysvinit function is here?

There is no equivalent behavior in sysvinit scripts.
I  mentioned that there.

> > +local
> > +#####
> > + * **systemd service**: ``cloud-init-local.service``
> > + * **runs**: As soon as / is mounted read-write.
> > + * **blocks**: as much of boot as possible, *must* block network bringup.
> > + * **modules**: none
> > +
> > +The purpose of the local stage is:
> > + * locate "local" data sources.
> > + * apply networking configuration to the system (including "Fallback")
> > +
> > +In most cases, this stage does not do much more than that.  It finds the
> > +datasource and determines the network configuration to be used.  That
> > +network configuration can come from:
> > +
> > + * the datasource
> > + * fallback: Cloud-init's fallback networking consists of rendering the
> > +   equivalent to "dhcp on eth0", which was historically the most popular
> > +   mechanism for network configuration of a guest.
> > + * none.  network configuration can be disabled entirely with '``network: {config: disabled}``'.
>
> by including the following cloud-config.

updated.

>
> > +
> > +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 affects such as dchp
> > +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 bounce network
>
> s/bounce/restart

updated.
>
> > +devices.
> > +
> > +This stage requires networking configuration to be up, as it will fully
>
> s/configuration to be up/to be online/available
> s/it/cloud-init/

updated.
> > +This stage runs as late in boot as possible.  The goal is to provide run
> > +as if the system had fully booted.  Any scripts that a user is accustomed
>
> "to provide run" ?
> Maybe just drop the second sentence.

dropped.

-- 
https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/310386
Your team cloud init development team is requested to review the proposed merge of ~smoser/cloud-init:doc-boot-stages into cloud-init:master.