Merge "Small fixes in the common reference architecture docs"

This commit is contained in:
Zuul 2017-11-01 02:24:16 +00:00 committed by Gerrit Code Review
commit 2780a5f170

View File

@ -34,19 +34,19 @@ components.
manages them by writing files to their root directories.
* If serial console is used, the conductor launches console processes
locally. If the nova-serialproxy service (part of the Compute service)
it used, it has to be able to reach them. Otherwise, they have to be
directly accessible by the users.
locally. If the ``nova-serialproxy`` service (part of the Compute service)
is used, it has to be able to reach the conductors. Otherwise, they have to
be directly accessible by the users.
* There has to be mutual connectivity between the conductor and the nodes
* There must be mutual connectivity between the conductor and the nodes
being deployed or cleaned. See Networking_ for details.
* The provisioning ramdisk which runs the ``ironic-python-agent`` service
on start up.
.. warning::
The ``ironic-python-agent`` service is not intended to be used anywhere
other than a provisioning/cleaning ramdisk.
The ``ironic-python-agent`` service is not intended to be used or executed
anywhere other than a provisioning/cleaning ramdisk.
Hardware and drivers
--------------------
@ -105,7 +105,7 @@ Alternatively, several vendors provide *virtual media* implementations of the
boot interface. They work by pushing an ISO image to the node's `management
controller`_, and do not require either PXE or iPXE. If such boot
implementation is available for the hardware, it is recommended using it
for better scalability and security. Check your driver documentation at
for better scalability and security. Check your driver documentation at
:doc:`/admin/drivers` for details.
Deploy interface
@ -115,8 +115,10 @@ There are two deploy interfaces in-tree, ``iscsi`` and ``direct``. See
:doc:`../enabling-drivers` for explanation of the difference. With the
``iscsi`` deploy method, most of the deployment operations happen on the
conductor. If the Object Storage service (swift) or RadosGW is present in
the cloud, it is recommended to use the ``direct`` deploy method for better
scalability and reliability.
the environment, it is recommended to use the ``direct`` deploy method for
better scalability and reliability.
.. TODO(dtantsur): say something about the ansible deploy, when it's in
Hardware specifications
~~~~~~~~~~~~~~~~~~~~~~~
@ -125,9 +127,13 @@ The Bare Metal services does not impose too many restrictions on the
characteristics of hardware itself. However, keep in mind that
* By default, the Bare Metal service will pick the smallest hard drive that
is large than 4 GiB for deployment. A smaller hard drive can be used, but
is larger than 4 GiB for deployment. Another hard drive can be used, but it
requires setting :ref:`root device hints <root-device-hints>`.
.. note::
This device does not have to match the boot device set in BIOS (or similar
firmware).
* The machines should have enough RAM to fit the deployment/cleaning ramdisk
to run. The minimum varies greatly depending on the way the ramdisk was
built. For example, *tinyipa*, the TinyCoreLinux-based ramdisk used in the
@ -139,15 +145,20 @@ Image types
The Bare Metal service can deploy two types of images:
* *Whole-disk* images contain a complete partitioning table with all necessary
partitions. Such images are the most universal, but may be harder to build.
* *Whole-disk* images that contain a complete partitioning table with all
necessary partitions and a bootloader. Such images are the most universal,
but may be harder to build.
* *Partition images* contain only the root partition. The Bare Metal service
will create the necessary partitions and install a boot loader, if needed.
* *Partition images* that contain only the root partition. The Bare Metal
service will create the necessary partitions and install a boot loader,
if needed.
.. warning::
Partition images are only supported with GNU/Linux operating systems,
and requires the GRUB2 bootloader to be present on the root image.
Partition images are only supported with GNU/Linux operating systems.
.. warning::
If you plan on using local boot, your partition images must contain GRUB2
bootloader tools to enable ironic to set up the bootloader during deploy.
Local vs network boot
---------------------
@ -166,7 +177,8 @@ boot interfaces based on it:
managing it. Thus, nodes are able to reboot correctly, even if the Bare Metal
TFTP or HTTP service is down.
* Network boot (and iPXE) must be used when booting nodes from remote volumes.
* Network boot (and iPXE) must be used when booting nodes from remote volumes,
if the driver does not support attaching volumes out-of-band.
The default boot option for the cloud can be changed via the Bare Metal service
configuration file, for example:
@ -196,15 +208,15 @@ documentation. However, several considerations are common for all of them:
* There has to be a *cleaning* network, which is used by nodes during
the cleaning process. In the majority of cases, the same network should
be used as cleaning and provisioning for simplicity.
be used for cleaning and provisioning for simplicity.
Unless noted otherwise, everything in these sections apply to both networks.
Unless noted otherwise, everything in these sections apply to both networks.
* The baremetal nodes have to have access to the Bare Metal API while connected
* The baremetal nodes must have access to the Bare Metal API while connected
to the provisioning/cleaning network.
.. note::
Actually, only two endpoints need to be exposed there::
Only two endpoints need to be exposed there::
GET /v1/lookup
POST /v1/heartbeat/[a-z0-9\-]+
@ -230,8 +242,8 @@ documentation. However, several considerations are common for all of them:
* either an HTTP server or the Object Storage service in case of the
``direct`` deploy interface and some virtual media boot interfaces
* The Baremetal Conductor needs to have access to the booted baremetal nodes
during provisioning/cleaning. The conductor communicates with an internal
* The Baremetal Conductors need to have access to the booted baremetal nodes
during provisioning/cleaning. A conductor communicates with an internal
API, provided by **ironic-python-agent**, to conduct actions on nodes.
HA and Scalability
@ -244,8 +256,9 @@ The Bare Metal API service is stateless, and thus can be easily scaled
horizontally. It is recommended to deploy it as a WSGI application behind e.g.
Apache or another WSGI container.
Note, that this service accesses the ironic database for reading entities
(e.g. in response to ``GET /v1/nodes`` request) and in rare cases for writing.
.. note::
This service accesses the ironic database for reading entities (e.g. in
response to ``GET /v1/nodes`` request) and in rare cases for writing.
ironic-conductor
~~~~~~~~~~~~~~~~