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