Make tox -e docs work
There were some problems in the documentaiton that prevented tox -e docs from working. Also changed attention to WARNING since attention was not as eye-grabbing as I'd hoped during a previous review. Change-Id: I2b661afa2cd4a4331bbcc99240d3e127a5d94a11
This commit is contained in:
parent
6667bcfc97
commit
755d5172b3
@ -147,8 +147,8 @@ Kolla images.
|
|||||||
|
|
||||||
This offers a lot of flexibility on how images are built, e.g. installing extra
|
This offers a lot of flexibility on how images are built, e.g. installing extra
|
||||||
packages as part of the build, tweaking settings, installing plugins, and
|
packages as part of the build, tweaking settings, installing plugins, and
|
||||||
numerous other capabilities. Some of these examples are described in more detail
|
numerous other capabilities. Some of these examples are described in more
|
||||||
below.
|
detail below.
|
||||||
|
|
||||||
Generic Customisation
|
Generic Customisation
|
||||||
---------------------
|
---------------------
|
||||||
@ -188,8 +188,8 @@ Package Customisation
|
|||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
Packages installed as part of a container build can be overridden, appended to,
|
Packages installed as part of a container build can be overridden, appended to,
|
||||||
and deleted. Taking the Horizon example, the following packages are installed as
|
and deleted. Taking the Horizon example, the following packages are installed
|
||||||
part of a binary install type build:
|
as part of a binary install type build:
|
||||||
|
|
||||||
* ``openstack-dashboard``
|
* ``openstack-dashboard``
|
||||||
* ``httpd``
|
* ``httpd``
|
||||||
|
@ -49,8 +49,9 @@ and OverlayFS. In order to update kernel in Ubuntu 14.04 LTS to 4.2, run:
|
|||||||
|
|
||||||
apt-get install linux-image-generic-lts-wily
|
apt-get install linux-image-generic-lts-wily
|
||||||
|
|
||||||
.. attention:: Operators performing an evaluation or deployment should use a
|
.. WARNING::
|
||||||
stable release. Operators performing development (or developers) should use
|
Operators performing an evaluation or deployment should use a stable
|
||||||
|
branch. Operators performing development (or developers) should use
|
||||||
master.
|
master.
|
||||||
|
|
||||||
.. note:: Install is *very* sensitive about version of components. Please
|
.. note:: Install is *very* sensitive about version of components. Please
|
||||||
@ -262,14 +263,15 @@ requirements it can be installed by:
|
|||||||
|
|
||||||
apt-get install ansible
|
apt-get install ansible
|
||||||
|
|
||||||
.. attention:: Kolla uses PBR in its implementation. PBR provides version
|
.. WARNING::
|
||||||
information to Kolla about the package in use. This information is later
|
Kolla uses PBR in its implementation. PBR provides version information
|
||||||
used when building images to specify the Docker tag used in the image built.
|
to Kolla about the package in use. This information is later used when
|
||||||
When installing the Kolla package via pip, PBR will always use the PBR version
|
building images to specify the Docker tag used in the image built. When
|
||||||
information. When obtaining a copy of the software via git, PBR will use the
|
installing the Kolla package via pip, PBR will always use the PBR version
|
||||||
git version information, but **ONLY** if Kolla has not been pip installed via
|
information. When obtaining a copy of the software via git, PBR will use
|
||||||
the pip package manager. This is why there is an operator workflow and a
|
the git version information, but **ONLY** if Kolla has not been pip
|
||||||
developer workflow.
|
installed via the pip package manager. This is why there is an operator
|
||||||
|
workflow and a developer workflow.
|
||||||
|
|
||||||
Installing Kolla for evaluation or deployment
|
Installing Kolla for evaluation or deployment
|
||||||
---------------------------------------------
|
---------------------------------------------
|
||||||
|
Loading…
Reference in New Issue
Block a user