openstack/openstack-ansible
Code Issues Proposed changes

DOCS: Configuration section - cleanup

Browse Source 
As per discussion in the OSA docs summit session, clean up
of installation guide. This fixes typos, minor RST mark up
changes, and passive voice.

This patch also merges a some of the sections into the larger
chapter. This is in an effort to remove multiple smaller
files.

This patch is the first of many to avoid major conflicts.

Change-Id: I2b1582812e638e2b3b455b7c34b93d13e08a168a
This commit is contained in:
Alexandra 2016-05-05 13:34:18 +10:00
parent 7fd7978e8e
commit 55155f301e
19 changed files with 540 additions and 575 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
doc/source/install-guide/configure-cinder-az.rst
View File

@ -1,37 +0,0 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Availability zones
------------------
Multiple availability zones can be created to manage Block Storage
storage hosts. Edit the
``/etc/openstack_deploy/openstack_user_config.yml`` and
``/etc/openstack_deploy/user_variables.yml`` files to set up
availability zones.
#. For each cinder storage host, configure the availability zone under
the ``container_vars`` stanza:
.. code-block:: yaml
cinder_storage_availability_zone: CINDERAZ
Replace ``CINDERAZ`` with a suitable name. For example
``cinderAZ_2``
#. If more than one availability zone is created, configure the default
availability zone for all the hosts by creating a
``cinder_default_availability_zone`` in your
``/etc/openstack_deploy/user_variables.yml``
.. code-block:: yaml
cinder_default_availability_zone: CINDERAZ_DEFAULT
Replace ``CINDERAZ_DEFAULT`` with a suitable name. For example,
``cinderAZ_1``. The default availability zone should be the same
for all cinder hosts.
--------------
.. include:: navigation.txt

79
doc/source/install-guide/configure-cinder-backup.rst
View File

@ -1,79 +0,0 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Backup
------
You can configure Block Storage (cinder) to back up volumes to Object
Storage (swift) by setting variables. If enabled, the default
configuration backs up volumes to an Object Storage installation
accessible within your environment. Alternatively, you can set
``cinder_service_backup_swift_url`` and other variables listed below to
back up to an external Object Storage installation.
#. Add or edit the following line in the
``/etc/openstack_deploy/user_variables.yml`` file and set the value
to ``True``:
.. code-block:: yaml
cinder_service_backup_program_enabled: True
#. By default, Block Storage will use the access credentials of the user
initiating the backup. Default values are set in the
``/opt/openstack-ansible/playbooks/roles/os_cinder/defaults/main.yml``
file. You can override those defaults by setting variables in
``/etc/openstack_deploy/user_variables.yml`` to change how Block
Storage performs backups. As needed, add and edit any of the
following variables to the
``/etc/openstack_deploy/user_variables.yml`` file:
.. code-block:: yaml
...
cinder_service_backup_swift_auth: per_user
# Options include 'per_user' or 'single_user'. We default to
# 'per_user' so that backups are saved to a user's swift
# account.
cinder_service_backup_swift_url:
# This is your swift storage url when using 'per_user', or keystone
# endpoint when using 'single_user'. When using 'per_user', you
# can leave this as empty or as None to allow cinder-backup to
# obtain storage url from environment.
cinder_service_backup_swift_url:
cinder_service_backup_swift_auth_version: 2
cinder_service_backup_swift_user:
cinder_service_backup_swift_tenant:
cinder_service_backup_swift_key:
cinder_service_backup_swift_container: volumebackups
cinder_service_backup_swift_object_size: 52428800
cinder_service_backup_swift_retry_attempts: 3
cinder_service_backup_swift_retry_backoff: 2
cinder_service_backup_compression_algorithm: zlib
cinder_service_backup_metadata_version: 2
During installation of Block Storage, the backup service is configured.
For more information about swift, refer to the Standalone Object Storage
Deployment guide.
Using Ceph for Cinder backups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Deployers can use Ceph to hold Cinder volume backups if they have Ceph
deployed. To get started, set the ``cinder_service_backup_driver`` Ansible
variable:
.. code-block:: yaml
cinder_service_backup_driver: cinder.backup.drivers.ceph
Next, configure the Ceph user and the pool to use for backups. The defaults
are shown here:
.. code-block:: yaml
cinder_service_backup_ceph_user: cinder-backup
cinder_service_backup_ceph_pool: backups
--------------
.. include:: navigation.txt

26
doc/source/install-guide/configure-cinder-horizon.rst
View File

@ -1,26 +0,0 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Horizon configuration for Cinder
--------------------------------
A deployer can configure variables to set the behavior for Cinder
volume management in Horizon. By default, no Horizon configuration is
set.
#. If multiple availability zones are used and
``cinder_default_availability_zone`` is not defined, the default
destination availability zone is ``nova``. Volume creation with
Horizon might fail if there is no availability zone named ``nova``.
Set ``cinder_default_availability_zone`` to an appropriate
availability zone name so that :guilabel:`Any availability zone`
works in Horizon.
#. Horizon does not populate the volume type by default. On the new
volume page, a request for the creation of a volume with the
default parameters fails. Set ``cinder_default_volume_type`` so
that a volume creation request without an explicit volume type
succeeds.
--------------
.. include:: navigation.txt

44
doc/source/install-guide/configure-cinder-nfs.rst
View File

@ -1,44 +0,0 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
NFS back-end
------------
If the NetApp back end is configured to use an NFS storage protocol,
edit ``/etc/openstack_deploy/openstack_user_config.yml``, and configure
the NFS client on each storage node that will use it.
#. Add the ``cinder_backends`` stanza (which includes
``cinder_nfs_client``) under the ``container_vars`` stanza for
each storage node:
.. code-block:: yaml
container_vars:
cinder_backends:
cinder_nfs_client:
#. Configure the location of the file that lists shares available to the
block storage service. This configuration file must include
``nfs_shares_config``:
.. code-block:: yaml
nfs_shares_config: SHARE_CONFIG
Replace ``SHARE_CONFIG`` with the location of the share
configuration file. For example, ``/etc/cinder/nfs_shares``.
#. Configure one or more NFS shares:
.. code-block:: yaml
shares:
- { ip: "NFS_HOST", share: "NFS_SHARE" }
Replace ``NFS_HOST`` with the IP address or hostname of the NFS
server, and the ``NFS_SHARE`` with the absolute path to an existing
and accessible NFS share.
--------------
.. include:: navigation.txt

253
doc/source/install-guide/configure-cinder.rst
View File

@ -1,29 +1,195 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide `Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring the Block Storage service (optional) Configuring the Block (cinder) storage service (optional)
------------------------------------------------ =========================================================
.. toctree:: By default, the Block (cinder) storage service installs on the host itself using
the LVM backend.
configure-cinder-nfs.rst .. note::
configure-cinder-backup.rst
configure-cinder-az.rst
configure-cinder-horizon.rst
By default, the Block Storage service installs on the host itself using the LVM While this is the default for cinder, using the LVM backend results in a
backend. While this is the default for cinder it should be noted that using a Single Point of Failure. As a result of the volume service being deployed
LVM backend results in a Single Point of Failure. As a result of the volume directly to the host, ``is_metal`` is ``true`` when using LVM.
service being deployed directly to the host is_metal is true when using LVM.
Configuring Cinder to use LVM NFS backend
~~~~~~~~~~~~
Edit ``/etc/openstack_deploy/openstack_user_config.yml`` and configure
the NFS client on each storage node if the NetApp backend is configured to use
an NFS storage protocol.
#. Add the ``cinder_backends`` stanza (which includes
``cinder_nfs_client``) under the ``container_vars`` stanza for
each storage node:
.. code-block:: yaml
container_vars:
cinder_backends:
cinder_nfs_client:
#. Configure the location of the file that lists shares available to the
block storage service. This configuration file must include
``nfs_shares_config``:
.. code-block:: yaml
nfs_shares_config: SHARE_CONFIG
Replace ``SHARE_CONFIG`` with the location of the share
configuration file. For example, ``/etc/cinder/nfs_shares``.
#. Configure one or more NFS shares:
.. code-block:: yaml
shares:
- { ip: "NFS_HOST", share: "NFS_SHARE" }
Replace ``NFS_HOST`` with the IP address or hostname of the NFS
server, and the ``NFS_SHARE`` with the absolute path to an existing
and accessible NFS share.
Backup
~~~~~~
You can configure cinder to backup volumes to Object
Storage (swift). Enable the default
configuration to back up volumes to a swift installation
accessible within your environment. Alternatively, you can set
``cinder_service_backup_swift_url`` and other variables to
back up to an external swift installation.
#. Add or edit the following line in the
``/etc/openstack_deploy/user_variables.yml`` file and set the value
to ``True``:
.. code-block:: yaml
cinder_service_backup_program_enabled: True
#. By default, cinder uses the access credentials of the user
initiating the backup. Default values are set in the
``/opt/openstack-ansible/playbooks/roles/os_cinder/defaults/main.yml``
file. You can override those defaults by setting variables in
``/etc/openstack_deploy/user_variables.yml`` to change how cinder
performs backups. Add and edit any of the
following variables to the
``/etc/openstack_deploy/user_variables.yml`` file:
.. code-block:: yaml
...
cinder_service_backup_swift_auth: per_user
# Options include 'per_user' or 'single_user'. We default to
# 'per_user' so that backups are saved to a user's swift
# account.
cinder_service_backup_swift_url:
# This is your swift storage url when using 'per_user', or keystone
# endpoint when using 'single_user'. When using 'per_user', you
# can leave this as empty or as None to allow cinder-backup to
# obtain a storage url from environment.
cinder_service_backup_swift_url:
cinder_service_backup_swift_auth_version: 2
cinder_service_backup_swift_user:
cinder_service_backup_swift_tenant:
cinder_service_backup_swift_key:
cinder_service_backup_swift_container: volumebackups
cinder_service_backup_swift_object_size: 52428800
cinder_service_backup_swift_retry_attempts: 3
cinder_service_backup_swift_retry_backoff: 2
cinder_service_backup_compression_algorithm: zlib
cinder_service_backup_metadata_version: 2
During installation of cinder, the backup service is configured.
Using Ceph for cinder backups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#. List the container_vars which contain the storage options for this target host. You can deploy Ceph to hold cinder volume backups.
Note that the vars related to the Cinder availability zone and the To get started, set the ``cinder_service_backup_driver`` Ansible
limit_container_types are optional. variable:
.. code-block:: yaml
cinder_service_backup_driver: cinder.backup.drivers.ceph
Configure the Ceph user and the pool to use for backups. The defaults
are shown here:
.. code-block:: yaml
cinder_service_backup_ceph_user: cinder-backup
cinder_service_backup_ceph_pool: backups
To configure an LVM you would utilize the following example: Availability zones
~~~~~~~~~~~~~~~~~~
Create multiple availability zones to manage cinder storage hosts. Edit the
``/etc/openstack_deploy/openstack_user_config.yml`` and
``/etc/openstack_deploy/user_variables.yml`` files to set up
availability zones.
#. For each cinder storage host, configure the availability zone under
the ``container_vars`` stanza:
.. code-block:: yaml
cinder_storage_availability_zone: CINDERAZ
Replace ``CINDERAZ`` with a suitable name. For example
``cinderAZ_2``.
#. If more than one availability zone is created, configure the default
availability zone for all the hosts by creating a
``cinder_default_availability_zone`` in your
``/etc/openstack_deploy/user_variables.yml``
.. code-block:: yaml
cinder_default_availability_zone: CINDERAZ_DEFAULT
Replace ``CINDERAZ_DEFAULT`` with a suitable name. For example,
``cinderAZ_1``. The default availability zone should be the same
for all cinder hosts.
OpenStack Dashboard (horizon) configuration for cinder
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can configure variables to set the behavior for cinder
volume management in OpenStack Dashboard (horizon).
By default, no horizon configuration is set.
#. The default destination availability zone is ``nova`` if you use
multiple availability zones and ``cinder_default_availability_zone``
has no definition. Volume creation with
horizon might fail if there is no availability zone named ``nova``.
Set ``cinder_default_availability_zone`` to an appropriate
availability zone name so that :guilabel:`Any availability zone`
works in horizon.
#. horizon does not populate the volume type by default. On the new
volume page, a request for the creation of a volume with the
default parameters fails. Set ``cinder_default_volume_type`` so
that a volume creation request without an explicit volume type
succeeds.
Configuring cinder to use LVM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#. List the ``container_vars`` that contain the storage options for the target host.
.. note::
The vars related to the cinder availability zone and the
``limit_container_types`` are optional.
To configure an LVM, utilize the following example:
.. code-block:: yaml .. code-block:: yaml
@ -41,22 +207,22 @@ Configuring Cinder to use LVM
iscsi_ip_address: "{{ storage_address }}" iscsi_ip_address: "{{ storage_address }}"
limit_container_types: cinder_volume limit_container_types: cinder_volume
If you rather use another backend (like Ceph, NetApp, etc.) in a To use another backend in a
container instead of bare metal, you may edit container instead of bare metal, edit
the ``/etc/openstack_deploy/env.d/cinder.yml`` and remove the the ``/etc/openstack_deploy/env.d/cinder.yml`` and remove the
``is_metal: true`` stanza under the cinder_volumes_container properties. ``is_metal: true`` stanza under the ``cinder_volumes_container`` properties.
Configuring Cinder to use Ceph Configuring cinder to use Ceph
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In order for Cinder to use Ceph it will be necessary to configure for both In order for cinder to use Ceph, it is necessary to configure for both
the API and backend. When using any forms of network storage the API and backend. When using any forms of network storage
(iSCSI, NFS, Ceph ) for cinder, the API containers can be considered (iSCSI, NFS, Ceph) for cinder, the API containers can be considered
as backend servers, so a separate storage host is not required. as backend servers. A separate storage host is not required.
In ``env.d/cinder.yml`` remove/disable ``is_metal: true`` In ``env.d/cinder.yml`` remove ``is_metal: true``
#. List of target hosts on which to deploy the cinder API. It is recommended #. List of target hosts on which to deploy the cinder API. We recommend
that a minumum of three target hosts are used for this service. that a minumum of three target hosts are used for this service.
.. code-block:: yaml .. code-block:: yaml
@ -70,7 +236,7 @@ In ``env.d/cinder.yml`` remove/disable ``is_metal: true``
ip: 172.29.236.103 ip: 172.29.236.103
To configure an RBD backend utilize the following example: To configure an RBD backend, utilize the following example:
.. code-block:: yaml .. code-block:: yaml
@ -97,7 +263,7 @@ The example uses cephx authentication and requires existing ``cinder``
account for ``cinder_volumes`` pool. account for ``cinder_volumes`` pool.
in ``user_variables.yml`` In ``user_variables.yml``:
.. code-block:: yaml .. code-block:: yaml
@ -108,9 +274,7 @@ in ``user_variables.yml``
- 172.29.244.153 - 172.29.244.153
In ``openstack_user_config.yml``:
in ``openstack_user_config.yml``
.. code-block:: yaml .. code-block:: yaml
@ -155,23 +319,24 @@ in ``openstack_user_config.yml``
This link provides a complete working example of ceph setup and This link provides a complete working example of Ceph setup and
integration with cinder (nova and glance included) integration with cinder (nova and glance included):
* `OpenStack-Ansible and Ceph Working Example`_ * `OpenStack-Ansible and Ceph Working Example`_
.. _OpenStack-Ansible and Ceph Working Example: https://www.openstackfaq.com/openstack-ansible-ceph/ .. _OpenStack-Ansible and Ceph Working Example: https://www.openstackfaq.com/openstack-ansible-ceph/
Configuring cinder to use a NetApp appliance
Configuring Cinder to use a NetApp appliance
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To use a NetApp storage appliance back end, edit the To use a NetApp storage appliance back end, edit the
``/etc/openstack_deploy/openstack_user_config.yml`` file and configure ``/etc/openstack_deploy/openstack_user_config.yml`` file and configure
each storage node that will use it: each storage node that will use it.
Ensure that the NAS Team enables httpd.admin.access. .. note::
Ensure that the NAS Team enables ``httpd.admin.access``.
#. Add the ``netapp`` stanza under the ``cinder_backends`` stanza for #. Add the ``netapp`` stanza under the ``cinder_backends`` stanza for
each storage node: each storage node:
@ -183,8 +348,7 @@ Ensure that the NAS Team enables httpd.admin.access.
The options in subsequent steps fit under the ``netapp`` stanza. The options in subsequent steps fit under the ``netapp`` stanza.
The back end name is arbitrary and becomes a volume type within the The backend name is arbitrary and becomes a volume type within cinder.
Block Storage service.
#. Configure the storage family: #. Configure the storage family:
@ -205,9 +369,8 @@ Ensure that the NAS Team enables httpd.admin.access.
Replace ``STORAGE_PROTOCOL`` with ``iscsi`` for iSCSI or ``nfs`` Replace ``STORAGE_PROTOCOL`` with ``iscsi`` for iSCSI or ``nfs``
for NFS. for NFS.
For the NFS protocol, you must also specify the location of the For the NFS protocol, specify the location of the
configuration file that lists the shares available to the Block configuration file that lists the shares available to cinder:
Storage service:
.. code-block:: yaml .. code-block:: yaml
@ -255,10 +418,10 @@ Ensure that the NAS Team enables httpd.admin.access.
volume_backend_name: BACKEND_NAME volume_backend_name: BACKEND_NAME
Replace ``BACKEND_NAME`` with a suitable value that provides a hint Replace ``BACKEND_NAME`` with a value that provides a hint
for the Block Storage scheduler. For example, ``NETAPP_iSCSI``. for the cinder scheduler. For example, ``NETAPP_iSCSI``.
#. Check that the ``openstack_user_config.yml`` configuration is #. Ensure the ``openstack_user_config.yml`` configuration is
accurate: accurate:
.. code-block:: yaml .. code-block:: yaml
@ -288,6 +451,8 @@ Ensure that the NAS Team enables httpd.admin.access.
``nfs-common`` file across the hosts, transitioning from an LVM to a ``nfs-common`` file across the hosts, transitioning from an LVM to a
NetApp back end. NetApp back end.
-------------- --------------
.. include:: navigation.txt .. include:: navigation.txt

15
doc/source/install-guide/configure-creds.rst
View File

@ -1,7 +1,7 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide `Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring service credentials Configuring service credentials
------------------------------- ===============================
Configure credentials for each service in the Configure credentials for each service in the
``/etc/openstack_deploy/*_secrets.yml`` files. Consider using `Ansible ``/etc/openstack_deploy/*_secrets.yml`` files. Consider using `Ansible
@ -17,17 +17,20 @@ interfaces:
- ``keystone_auth_admin_password`` configures the ``admin`` tenant - ``keystone_auth_admin_password`` configures the ``admin`` tenant
password for both the OpenStack API and dashboard access. password for both the OpenStack API and dashboard access.
Recommended: Use the ``pw-token-gen.py`` script to generate random .. note::
values for the variables in each file that contains service credentials:
.. code-block:: shell-session We recommend using the ``pw-token-gen.py`` script to generate random
values for the variables in each file that contains service credentials:
# cd /opt/openstack-ansible/scripts .. code-block:: shell-session
# python pw-token-gen.py --file /etc/openstack_deploy/user_secrets.yml
# cd /opt/openstack-ansible/scripts
# python pw-token-gen.py --file /etc/openstack_deploy/user_secrets.yml
To regenerate existing passwords, add the ``--regen`` flag. To regenerate existing passwords, add the ``--regen`` flag.
.. warning:: .. warning::
The playbooks do not currently manage changing passwords in an existing The playbooks do not currently manage changing passwords in an existing
environment. Changing passwords and re-running the playbooks will fail environment. Changing passwords and re-running the playbooks will fail
and may break your OpenStack environment. and may break your OpenStack environment.

51
doc/source/install-guide/configure-glance.rst
View File

@ -1,24 +1,22 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide `Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring the Image Service Configuring the Image (glance) service
----------------------------- ======================================
In an all-in-one deployment with a single infrastructure node, the Image In an all-in-one deployment with a single infrastructure node, the Image
Service uses the local file system on the target host to store images. (glance) service uses the local file system on the target host to store images.
When deploying production clouds we recommend backing Glance with a When deploying production clouds, we recommend backing glance with a
swift backend or some form or another of shared storage. swift backend or some form of shared storage.
Configuring default and additional stores Configuring default and additional stores
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OpenStack-Ansible provides two configurations for controlling where the Image OpenStack-Ansible provides two configurations for controlling where glance stores
Service stores files: the default store and additional stores. As mentioned files: the default store and additional stores. glance stores images in file-based
in the previous section, the Image Service stores images in file-based storage storage by default. Two additional stores, ``http`` and ``cinder`` (Block Storage),
by default. Two additional stores, http and cinder, are also enabled by are also enabled by default.
default.
Deployers can choose alternative default stores, as shown in the swift example You can choose alternative default stores and alternative additional stores.
in the next section, and deployers can choose alternative additional stores.
For example, a deployer that uses Ceph may configure the following Ansible For example, a deployer that uses Ceph may configure the following Ansible
variables: variables:
@ -30,17 +28,17 @@ variables:
- http - http
- cinder - cinder
The configuration above will configure the Image Service to use rbd (Ceph) by The configuration above configures glance to use ``rbd`` (Ceph) by
default, but the swift, http and cinder stores will also be enabled in the default, but ``glance_additional_stores`` list enables ``swift``,
Image Service configuration files. ``http`` and ``cinder`` stores in the glance
configuration files.
The following example sets glance to use the ``images`` pool. The following example sets glance to use the ``images`` pool.
The example uses cephx authentication and requires an existing ``glance`` This example uses cephx authentication and requires an existing ``glance``
account for the ``images`` pool. account for the ``images`` pool.
in ``user_variables.yml`` In ``user_variables.yml``:
.. code-block:: yaml .. code-block:: yaml
@ -81,8 +79,7 @@ usage.
glance_swift_store_auth_version: 2 glance_swift_store_auth_version: 2
glance_swift_store_auth_address: https://127.0.0.1/v2.0 glance_swift_store_auth_address: https://127.0.0.1/v2.0
#. Set the swift account credentials (see *Special Considerations* at the #. Set the swift account credentials:
bottom of this page):
.. code-block:: yaml .. code-block:: yaml
@ -104,7 +101,7 @@ usage.
glance_swift_store_container: STORE_NAME glance_swift_store_container: STORE_NAME
Replace ``STORE_NAME`` with the container name in swift to be Replace ``STORE_NAME`` with the container name in swift to be
used for storing images. If the container doesn't exist, it will be used for storing images. If the container does not exist, it is
automatically created. automatically created.
#. Define the store region: #. Define the store region:
@ -121,10 +118,10 @@ usage.
glance_flavor: GLANCE_FLAVOR glance_flavor: GLANCE_FLAVOR
By default, the Image Service uses caching and authenticates with the By default, glance uses caching and authenticates with the
Identity service. The default maximum size of the image cache is 10 Identity (keystone) service. The default maximum size of the image cache is 10GB.
GB. The default Image Service container size is 12 GB. In some The default glance container size is 12GB. In some
configurations, the Image Service might attempt to cache an image configurations, glance attempts to cache an image
which exceeds the available disk space. If necessary, you can disable which exceeds the available disk space. If necessary, you can disable
caching. For example, to use Identity without caching, replace caching. For example, to use Identity without caching, replace
``GLANCE_FLAVOR`` with ``keystone``: ``GLANCE_FLAVOR`` with ``keystone``:
@ -163,12 +160,12 @@ usage.
- ``trusted-auth+cachemanagement`` - ``trusted-auth+cachemanagement``
Special Considerations Special considerations
~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~
If the swift password or key contains a dollar sign (``$``), it must If the swift password or key contains a dollar sign (``$``), it must
be escaped with an additional dollar sign (``$$``). For example, a password of be escaped with an additional dollar sign (``$$``). For example, a password of
``super$ecure`` would need to be entered as ``super$$ecure``. This is needed ``super$ecure`` would need to be entered as ``super$$ecure``. This is necessary
due to the way `oslo.config formats strings`_. due to the way `oslo.config formats strings`_.
.. _oslo.config formats strings: https://bugs.launchpad.net/oslo-incubator/+bug/1259729 .. _oslo.config formats strings: https://bugs.launchpad.net/oslo-incubator/+bug/1259729

8
doc/source/install-guide/configure-hostlist.rst
View File

@ -1,7 +1,7 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide `Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring target hosts Configuring target hosts
------------------------ ========================
Modify the ``/etc/openstack_deploy/openstack_user_config.yml`` file to Modify the ``/etc/openstack_deploy/openstack_user_config.yml`` file to
configure the target hosts. configure the target hosts.
@ -70,7 +70,7 @@ the ``br-mgmt`` container management bridge on each target host.
network02: ... network02: ...
Providing more than one network host in the ``network_hosts`` block will Providing more than one network host in the ``network_hosts`` block will
enable `L3HA support using VRRP`_ in the neutron-agent containers. enable `L3HA support using VRRP`_ in the ``neutron-agent`` containers.
.. _L3HA support using VRRP: http://docs.openstack.org/liberty/networking-guide/scenario_l3ha_lb.html .. _L3HA support using VRRP: http://docs.openstack.org/liberty/networking-guide/scenario_l3ha_lb.html
@ -120,12 +120,12 @@ the ``br-mgmt`` container management bridge on each target host.
ip: STORAGE01_IP_ADDRESS ip: STORAGE01_IP_ADDRESS
storage02: ... storage02: ...
Each storage host also requires additional configuration to define the back end Each storage host requires additional configuration to define the back end
driver. driver.
The default configuration includes an optional storage host. To The default configuration includes an optional storage host. To
install without storage hosts, comment out the stanza beginning with install without storage hosts, comment out the stanza beginning with
the *storage\_hosts:* line. the *storage_hosts:* line.
-------------- --------------

2
doc/source/install-guide/configure-hypervisor.rst
View File

@ -1,7 +1,7 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide `Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring the hypervisor (optional) Configuring the hypervisor (optional)
------------------------------------- =====================================
By default, the KVM hypervisor is used. If you are deploying to a host By default, the KVM hypervisor is used. If you are deploying to a host
that does not support KVM hardware acceleration extensions, select a that does not support KVM hardware acceleration extensions, select a

54
doc/source/install-guide/configure-initial.rst
View File

@ -1,12 +1,12 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide `Home <index.html>`_ OpenStack-Ansible Installation Guide
Initial environment configuration Initial environment configuration
--------------------------------- =================================
OpenStack-Ansible depends on various files that are used to build an inventory OpenStack-Ansible depends on various files that are used to build an inventory
for Ansible. Start by getting those files into the correct places: for Ansible. Start by getting those files into the correct places:
#. Recursively copy the contents of the #. Copy the contents of the
``/opt/openstack-ansible/etc/openstack_deploy`` directory to the ``/opt/openstack-ansible/etc/openstack_deploy`` directory to the
``/etc/openstack_deploy`` directory. ``/etc/openstack_deploy`` directory.
@ -15,30 +15,32 @@ for Ansible. Start by getting those files into the correct places:
#. Copy the ``openstack_user_config.yml.example`` file to #. Copy the ``openstack_user_config.yml.example`` file to
``/etc/openstack_deploy/openstack_user_config.yml``. ``/etc/openstack_deploy/openstack_user_config.yml``.
Deployers can review the ``openstack_user_config.yml`` file and make changes You can review the ``openstack_user_config.yml`` file and make changes
to how the OpenStack environment is deployed. The file is **heavily** commented to the deployment of your OpenStack environment.
with details about the various options.
There are various types of physical hosts that will host containers that are .. note::
The file is heavily commented with details about the various options.
There are various types of physical hardware that are able to use containers
deployed by OpenStack-Ansible. For example, hosts listed in the deployed by OpenStack-Ansible. For example, hosts listed in the
`shared-infra_hosts` will run containers for many of the shared services `shared-infra_hosts` run containers for many of the shared services that
required by OpenStack environments. Some of these services include databases, your OpenStack environments requires. Some of these services include databases,
memcache, and RabbitMQ. There are several other host types that contain memcached, and RabbitMQ. There are several other host types that contain
other types of containers and all of these are listed in other types of containers and all of these are listed in
``openstack_user_config.yml``. ``openstack_user_config.yml``.
For details about how the inventory is generated from the environment For details about how the inventory is generated from the environment
configuration, please see :ref:`developer-inventory`. configuration, see :ref:`developer-inventory`.
Affinity Affinity
^^^^^^^^ ~~~~~~~~
OpenStack-Ansible's dynamic inventory generation has a concept called OpenStack-Ansible's dynamic inventory generation has a concept called
*affinity*. This determines how many containers of a similar type are deployed `affinity`. This determines how many containers of a similar type are deployed
onto a single physical host. onto a single physical host.
Using `shared-infra_hosts` as an example, let's consider a Using `shared-infra_hosts` as an example, consider this ``openstack_user_config.yml``:
``openstack_user_config.yml`` that looks like this:
.. code-block:: yaml .. code-block:: yaml
@ -50,15 +52,15 @@ Using `shared-infra_hosts` as an example, let's consider a
infra3: infra3:
ip: 172.29.236.103 ip: 172.29.236.103
Three hosts are assigned to the `shared-infra_hosts` group, so Three hosts are assigned to the `shared-infra_hosts` group,
OpenStack-Ansible will ensure that each host runs a single database container, OpenStack-Ansible ensures that each host runs a single database container,
a single memcached container, and a single RabbitMQ container. Each host has a single memcached container, and a single RabbitMQ container. Each host has
an affinity of 1 by default, and that means each host will run one of each an affinity of 1 by default, and that means each host will run one of each
container type. container type.
Some deployers may want to skip the deployment of RabbitMQ altogether. This is You can skip the deployment of RabbitMQ altogether. This is
helpful when deploying a standalone swift environment. For deployers who need helpful when deploying a standalone swift environment. If you need
this configuration, their ``openstack_user_config.yml`` would look like this: this configuration, your ``openstack_user_config.yml`` would look like this:
.. code-block:: yaml .. code-block:: yaml
@ -76,14 +78,14 @@ this configuration, their ``openstack_user_config.yml`` would look like this:
rabbit_mq_container: 0 rabbit_mq_container: 0
ip: 172.29.236.103 ip: 172.29.236.103
The configuration above would still deploy a memcached container and a database The configuration above deploys a memcached container and a database
container on each host, but there would be no RabbitMQ containers deployed. container on each host, without the RabbitMQ containers.
.. _security_hardening: .. _security_hardening:
Security Hardening Security hardening
^^^^^^^^^^^^^^^^^^ ~~~~~~~~~~~~~~~~~~
OpenStack-Ansible automatically applies host security hardening configurations OpenStack-Ansible automatically applies host security hardening configurations
using the `openstack-ansible-security`_ role. The role uses a version of the using the `openstack-ansible-security`_ role. The role uses a version of the
@ -91,8 +93,8 @@ using the `openstack-ansible-security`_ role. The role uses a version of the
Ubuntu 14.04 and OpenStack. Ubuntu 14.04 and OpenStack.
The role is applicable to physical hosts within an OpenStack-Ansible deployment The role is applicable to physical hosts within an OpenStack-Ansible deployment
that are operating as any type of node -- infrastructure or compute. By that are operating as any type of node, infrastructure or compute. By
default, the role is enabled. Deployers can disable it by changing a variable default, the role is enabled. You can disable it by changing a variable
within ``user_variables.yml``: within ``user_variables.yml``:
.. code-block:: yaml .. code-block:: yaml
@ -102,7 +104,7 @@ within ``user_variables.yml``:
When the variable is set to ``true``, the ``setup-hosts.yml`` playbook applies When the variable is set to ``true``, the ``setup-hosts.yml`` playbook applies
the role during deployments. the role during deployments.
Deployers can apply security configurations to an existing environment or audit You can apply security configurations to an existing environment or audit
an environment using a playbook supplied with OpenStack-Ansible: an environment using a playbook supplied with OpenStack-Ansible:
.. code-block:: bash .. code-block:: bash

21
doc/source/install-guide/configure-ironic-baremetal-node.rst
View File

@ -1,21 +0,0 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Deploy a baremetal node kicked with Ironic
------------------------------------------
.. important::
You will not have access unless you have a key set within Nova before
your Ironic deployment. If you do not have an ssh key readily
available, set one up with ``ssh-keygen``.
.. code-block:: bash
nova keypair-add --pub-key ~/.ssh/id_rsa.pub admin
Now boot a node:
.. code-block:: bash
nova boot --flavor ${FLAVOR_NAME} --image ${IMAGE_NAME} --key-name admin ${NODE_NAME}

12
doc/source/install-guide/configure-ironic-deployment.rst
View File

@ -1,12 +0,0 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
OpenStack-Ansible deployment
----------------------------
#. Modify the environment files and force ``nova-compute`` to run from
within a container:
.. code-block:: bash
sed -i '/is_metal.*/d' /etc/openstack_deploy/env.d/nova.yml

30
doc/source/install-guide/configure-ironic-flavor.rst
View File

@ -1,30 +0,0 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Creating an Ironic flavor
-------------------------
#. Create a new flavor called ``my-baremetal-flavor``.
.. note::
The following example sets the CPU architecture for the newly created
flavor to be `x86_64`.
.. code-block:: bash
nova flavor-create ${FLAVOR_NAME} ${FLAVOR_ID} ${FLAVOR_RAM} ${FLAVOR_DISK} ${FLAVOR_CPU}
nova flavor-key ${FLAVOR_NAME} set cpu_arch=x86_64
nova flavor-key ${FLAVOR_NAME} set capabilities:boot_option="local"
.. note::
The flavor and nodes should match when enrolling into Ironic.
See the documentation on flavors for more information:
http://docs.openstack.org/openstack-ops/content/flavors.html
After successfully deploying the ironic node on subsequent boots, the instance
will boot from your local disk as first preference. This will speed up the deployed
node's boot time. The alternative, if this is not set, will mean the ironic node will
attempt to PXE boot first, which will allow for operator-initiated image updates and
other operations. The operational reasoning and building an environment to support this
use case is not covered here.

66
doc/source/install-guide/configure-ironic-images.rst
View File

@ -1,66 +0,0 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Building Ironic images
----------------------
Images using the ``diskimage-builder`` must be built outside of a container.
For this process, use one of the physical hosts within the environment.
#. Install the necessary packages:
.. code-block:: bash
apt-get install -y qemu uuid-runtime curl
#. Install the ``disk-imagebuilder`` client:
.. code-block:: bash
pip install diskimage-builder --isolated
.. important::
Only use the ``--isolated`` flag if you are building on a node that
has already been deployed by OpenStack-Ansible as pip will not
allow the external package to be resolved.
#. Optional: Force the ubuntu ``image-create`` process to use a modern kernel:
.. code-block:: bash
echo 'linux-image-generic-lts-xenial:' > /usr/local/share/diskimage-builder/elements/ubuntu/package-installs.yaml
#. Create Ubuntu ``initramfs``:
.. code-block:: bash
disk-image-create ironic-agent ubuntu -o ${IMAGE_NAME}
#. Upload the created deploy images into the Image Service:
.. code-block:: bash
# Upload the deploy image kernel
glance image-create --name ${IMAGE_NAME}.kernel --visibility public --disk-format aki --container-format aki < ${IMAGE_NAME}.kernel
# Upload the user image initramfs
glance image-create --name ${IMAGE_NAME}.initramfs --visibility public --disk-format ari --container-format ari < ${IMAGE_NAME}.initramfs
#. Create Ubuntu user image:
.. code-block:: bash
disk-image-create ubuntu baremetal localboot local-config dhcp-all-interfaces grub2 -o ${IMAGE_NAME}
#. Upload the created user images into the Image Service:
.. code-block:: bash
# Upload the user image vmlinuz and store uuid
VMLINUZ_UUID="$(glance image-create --name ${IMAGE_NAME}.vmlinuz --visibility public --disk-format aki --container-format aki < ${IMAGE_NAME}.vmlinuz | awk '/\| id/ {print $4}')"
# Upload the user image initrd and store uuid
INITRD_UUID="$(glance image-create --name ${IMAGE_NAME}.initrd --visibility public --disk-format ari --container-format ari < ${IMAGE_NAME}.initrd | awk '/\| id/ {print $4}')"
# Create image
glance image-create --name ${IMAGE_NAME} --visibility public --disk-format qcow2 --container-format bare --property kernel_id=${VMLINUZ_UUID} --property ramdisk_id=${INITRD_UUID} < ${IMAGE_NAME}.qcow2

22
doc/source/install-guide/configure-ironic-neutron.rst
View File

@ -1,22 +0,0 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Setup a Neutron network for use Ironic
--------------------------------------
In the general case, the Neutron network can be a simple flat network. However,
in a complex case, this can be whatever you need and want. Ensure
you adjust the deployment accordingly. The following is an example:
.. code-block:: bash
neutron net-create cleaning-net --shared \
--provider:network_type flat \
--provider:physical_network ironic-net
neutron subnet-create ironic-net 172.19.0.0/22 --name ironic-subnet
--ip-version=4 \
--allocation-pool start=172.19.1.100,end=172.19.1.200 \
--enable-dhcp \
--dns-nameservers list=true 8.8.4.4 8.8.8.8

52
doc/source/install-guide/configure-ironic-nodes.rst
View File

@ -1,52 +0,0 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Enroll Ironic nodes
-------------------
#. From the utility container, enroll a new baremetal node by executing the following:
.. code-block:: bash
# Source credentials
. ~/openrc
# Create the node
NODE_HOSTNAME="myfirstnodename"
IPMI_ADDRESS="10.1.2.3"
IPMI_USER="my-ipmi-user"
IPMI_PASSWORD="my-ipmi-password"
KERNEL_IMAGE=$(glance image-list | awk "/${IMAGE_NAME}.kernel/ {print \$2}")
INITRAMFS_IMAGE=$(glance image-list | awk "/${IMAGE_NAME}.initramfs/ {print \$2}")
ironic node-create \
-d agent_ipmitool \
-i ipmi_address="${IPMI_ADDRESS}" \
-i ipmi_username="${IPMI_USER}" \
-i ipmi_password="${IPMI_PASSWORD}" \
-i deploy_ramdisk="${INITRAMFS_IMAGE}" \
-i deploy_kernel="${KERNEL_IMAGE}" \
-n ${NODE_HOSTNAME}
# Create a port for the node
NODE_MACADDRESS="aa:bb:cc:dd:ee:ff"
ironic port-create \
-n $(ironic node-list | awk "/${NODE_HOSTNAME}/ {print \$2}") \
-a ${NODE_MACADDRESS}
# Associate an image to the node
ROOT_DISK_SIZE_GB=40
ironic node-update $(ironic node-list | awk "/${IMAGE_NAME}/ {print \$2}") add \
driver_info/deploy_kernel=$KERNEL_IMAGE \
driver_info/deploy_ramdisk=$INITRAMFS_IMAGE \
instance_info/deploy_kernel=$KERNEL_IMAGE \
instance_info/deploy_ramdisk=$INITRAMFS_IMAGE \
instance_info/root_gb=${ROOT_DISK_SIZE_GB}
# Add node properties
# The property values used here should match the hardware used
ironic node-update $(ironic node-list | awk "/${NODE_HOSTNAME}/ {print \$2}") add \
properties/cpus=48 \
properties/memory_mb=254802 \
properties/local_gb=80 \
properties/size=3600 \
properties/cpu_arch=x86_64 \
properties/capabilities=memory_mb:254802,local_gb:80,cpu_arch:x86_64,cpus:48,boot_option:local

222
doc/source/install-guide/configure-ironic.rst
View File

@ -1,28 +1,220 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide `Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring the ironic service (optional) Configuring the Bare Metal (ironic) service (optional)
----------------------------------------- ======================================================
.. note:: .. note::
This feature is experimental at this time and it has not been fully production This feature is experimental at this time and it has not been fully production
tested yet. This implementation instructions assume that Ironic is being deployed tested yet. These implementation instructions assume that ironic is being deployed
as the sole hypervisor for the region. as the sole hypervisor for the region.
.. toctree::
configure-ironic-deployment.rst
configure-ironic-neutron.rst
configure-ironic-images.rst
configure-ironic-flavor.rst
configure-ironic-nodes.rst
configure-ironic-baremetal-node.rst
Ironic is an OpenStack project which provisions bare metal (as opposed to virtual) Ironic is an OpenStack project which provisions bare metal (as opposed to virtual)
machines by leveraging common technologies such as PXE boot and IPMI to cover a wide machines by leveraging common technologies such as PXE boot and IPMI to cover a wide
range of hardware, while supporting pluggable drivers to allow vendor-specific range of hardware, while supporting pluggable drivers to allow vendor-specific
functionality to be added. functionality to be added.
OpenStack’s Ironic project makes physical servers as easy to provision as OpenStack’s ironic project makes physical servers as easy to provision as
virtual machines in a cloud, which in turn will open up new avenues for enterprises virtual machines in a cloud.
and service providers.
OpenStack-Ansible deployment
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#. Modify the environment files and force ``nova-compute`` to run from
within a container:
.. code-block:: bash
sed -i '/is_metal.*/d' /etc/openstack_deploy/env.d/nova.yml
Setup a neutron network for use by ironic
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In a general case, neutron networking can be a simple flat network. However,
in a complex case, this can be whatever you need and want. Ensure
you adjust the deployment accordingly. The following is an example:
.. code-block:: bash
neutron net-create cleaning-net --shared \
--provider:network_type flat \
--provider:physical_network ironic-net
neutron subnet-create ironic-net 172.19.0.0/22 --name ironic-subnet
--ip-version=4 \
--allocation-pool start=172.19.1.100,end=172.19.1.200 \
--enable-dhcp \
--dns-nameservers list=true 8.8.4.4 8.8.8.8
Building ironic images
~~~~~~~~~~~~~~~~~~~~~~
Images using the ``diskimage-builder`` must be built outside of a container.
For this process, use one of the physical hosts within the environment.
#. Install the necessary packages:
.. code-block:: bash
apt-get install -y qemu uuid-runtime curl
#. Install the ``disk-imagebuilder`` package:
.. code-block:: bash
pip install diskimage-builder --isolated
.. important::
Only use the ``--isolated`` flag if you are building on a node
deployed by OpenStack-Ansible, otherwise pip will not
resolve the external package.
#. Optional: Force the ubuntu ``image-create`` process to use a modern kernel:
.. code-block:: bash
echo 'linux-image-generic-lts-xenial:' > \
/usr/local/share/diskimage-builder/elements/ubuntu/package-installs.yaml
#. Create Ubuntu ``initramfs``:
.. code-block:: bash
disk-image-create ironic-agent ubuntu -o ${IMAGE_NAME}
#. Upload the created deploy images into the Image (glance) Service:
.. code-block:: bash
# Upload the deploy image kernel
glance image-create --name ${IMAGE_NAME}.kernel --visibility public \
--disk-format aki --container-format aki < ${IMAGE_NAME}.kernel
# Upload the user image initramfs
glance image-create --name ${IMAGE_NAME}.initramfs --visibility public \
--disk-format ari --container-format ari < ${IMAGE_NAME}.initramfs
#. Create Ubuntu user image:
.. code-block:: bash
disk-image-create ubuntu baremetal localboot local-config dhcp-all-interfaces grub2 -o ${IMAGE_NAME}
#. Upload the created user images into the Image (glance) Service:
.. code-block:: bash
# Upload the user image vmlinuz and store uuid
VMLINUZ_UUID="$(glance image-create --name ${IMAGE_NAME}.vmlinuz --visibility public --disk-format aki --container-format aki < ${IMAGE_NAME}.vmlinuz | awk '/\| id/ {print $4}')"
# Upload the user image initrd and store uuid
INITRD_UUID="$(glance image-create --name ${IMAGE_NAME}.initrd --visibility public --disk-format ari --container-format ari < ${IMAGE_NAME}.initrd | awk '/\| id/ {print $4}')"
# Create image
glance image-create --name ${IMAGE_NAME} --visibility public --disk-format qcow2 --container-format bare --property kernel_id=${VMLINUZ_UUID} --property ramdisk_id=${INITRD_UUID} < ${IMAGE_NAME}.qcow2
Creating an ironic flavor
~~~~~~~~~~~~~~~~~~~~~~~~~
#. Create a new flavor called ``my-baremetal-flavor``.
.. note::
The following example sets the CPU architecture for the newly created
flavor to be `x86_64`.
.. code-block:: bash
nova flavor-create ${FLAVOR_NAME} ${FLAVOR_ID} ${FLAVOR_RAM} ${FLAVOR_DISK} ${FLAVOR_CPU}
nova flavor-key ${FLAVOR_NAME} set cpu_arch=x86_64
nova flavor-key ${FLAVOR_NAME} set capabilities:boot_option="local"
.. note::
Ensure the flavor and nodes match when enrolling into ironic.
See the documentation on flavors for more information:
http://docs.openstack.org/openstack-ops/content/flavors.html
After successfully deploying the ironic node on subsequent boots, the instance
boots from your local disk as first preference. This speeds up the deployed
node's boot time. Alternatively, if this is not set, the ironic node PXE boots first and
allows for operator-initiated image updates and other operations.
.. note::
The operational reasoning and building an environment to support this
use case is not covered here.
Enroll ironic nodes
-------------------
#. From the utility container, enroll a new baremetal node by executing the following:
.. code-block:: bash
# Source credentials
. ~/openrc
# Create the node
NODE_HOSTNAME="myfirstnodename"
IPMI_ADDRESS="10.1.2.3"
IPMI_USER="my-ipmi-user"
IPMI_PASSWORD="my-ipmi-password"
KERNEL_IMAGE=$(glance image-list | awk "/${IMAGE_NAME}.kernel/ {print \$2}")
INITRAMFS_IMAGE=$(glance image-list | awk "/${IMAGE_NAME}.initramfs/ {print \$2}")
ironic node-create \
-d agent_ipmitool \
-i ipmi_address="${IPMI_ADDRESS}" \
-i ipmi_username="${IPMI_USER}" \
-i ipmi_password="${IPMI_PASSWORD}" \
-i deploy_ramdisk="${INITRAMFS_IMAGE}" \
-i deploy_kernel="${KERNEL_IMAGE}" \
-n ${NODE_HOSTNAME}
# Create a port for the node
NODE_MACADDRESS="aa:bb:cc:dd:ee:ff"
ironic port-create \
-n $(ironic node-list | awk "/${NODE_HOSTNAME}/ {print \$2}") \
-a ${NODE_MACADDRESS}
# Associate an image to the node
ROOT_DISK_SIZE_GB=40
ironic node-update $(ironic node-list | awk "/${IMAGE_NAME}/ {print \$2}") add \
driver_info/deploy_kernel=$KERNEL_IMAGE \
driver_info/deploy_ramdisk=$INITRAMFS_IMAGE \
instance_info/deploy_kernel=$KERNEL_IMAGE \
instance_info/deploy_ramdisk=$INITRAMFS_IMAGE \
instance_info/root_gb=${ROOT_DISK_SIZE_GB}
# Add node properties
# The property values used here should match the hardware used
ironic node-update $(ironic node-list | awk "/${NODE_HOSTNAME}/ {print \$2}") add \
properties/cpus=48 \
properties/memory_mb=254802 \
properties/local_gb=80 \
properties/size=3600 \
properties/cpu_arch=x86_64 \
properties/capabilities=memory_mb:254802,local_gb:80,cpu_arch:x86_64,cpus:48,boot_option:local
Deploy a baremetal node kicked with ironic
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. important::
You will not have access unless you have a key set within nova before
your ironic deployment. If you do not have an ssh key readily
available, set one up with ``ssh-keygen``.
.. code-block:: bash
nova keypair-add --pub-key ~/.ssh/id_rsa.pub admin
Now boot a node:
.. code-block:: bash
nova boot --flavor ${FLAVOR_NAME} --image ${IMAGE_NAME} --key-name admin ${NODE_NAME}

29
doc/source/install-guide/configure-networking.rst
View File

@ -3,7 +3,7 @@
.. _network_configuration: .. _network_configuration:
Configuring target host networking Configuring target host networking
---------------------------------- ==================================
Edit the ``/etc/openstack_deploy/openstack_user_config.yml`` file to Edit the ``/etc/openstack_deploy/openstack_user_config.yml`` file to
configure target host networking. configure target host networking.
@ -26,10 +26,10 @@ configure target host networking.
notation. For example, 203.0.113.0/24. notation. For example, 203.0.113.0/24.
Use the same IP address ranges as the underlying physical network Use the same IP address ranges as the underlying physical network
interfaces or bridges configured in `the section called "Configuring interfaces or bridges in `the section called "Configuring
the network" <targethosts-network.html>`_. For example, if the the network" <targethosts-network.html>`_. For example, if the
container network uses 203.0.113.0/24, the ``CONTAINER_MGMT_CIDR`` container network uses 203.0.113.0/24, the ``CONTAINER_MGMT_CIDR``
should also use 203.0.113.0/24. also uses 203.0.113.0/24.
The default configuration includes the optional storage and service The default configuration includes the optional storage and service
networks. To remove one or both of them, comment out the appropriate networks. To remove one or both of them, comment out the appropriate
@ -44,11 +44,10 @@ configure target host networking.
Replace ``EXISTING_IP_ADDRESSES`` with a list of existing IP Replace ``EXISTING_IP_ADDRESSES`` with a list of existing IP
addresses in the ranges defined in the previous step. This list addresses in the ranges defined in the previous step. This list
should include all IP addresses manually configured on target hosts should include all IP addresses manually configured on target hosts,
in the `the section called "Configuring the internal load balancers, service network bridge, deployment hosts and
network" <targethosts-network.html>`_, internal load balancers, any other devices to avoid conflicts during the automatic IP address
service network bridge, deployment hosts and any other devices generation process.
to avoid conflicts during the automatic IP address generation process.
Add individual IP addresses on separate lines. For example, to Add individual IP addresses on separate lines. For example, to
prevent use of 203.0.113.101 and 201: prevent use of 203.0.113.101 and 201:
@ -132,7 +131,7 @@ configure target host networking.
The default configuration includes the optional storage and service The default configuration includes the optional storage and service
networks. To remove one or both of them, comment out the entire networks. To remove one or both of them, comment out the entire
associated stanza beginning with the *- network:* line. associated stanza beginning with the ``- network:`` line.
#. Configure OpenStack Networking VXLAN tunnel/overlay networks in the #. Configure OpenStack Networking VXLAN tunnel/overlay networks in the
``provider_networks`` subsection: ``provider_networks`` subsection:
@ -185,16 +184,16 @@ configure target host networking.
additional network. additional network.
Replace ``PHYSICAL_NETWORK_INTERFACE`` with the network interface used for Replace ``PHYSICAL_NETWORK_INTERFACE`` with the network interface used for
flat networking. This **must** be a physical interface on the same L2 network flat networking. Ensure this is a physical interface on the same L2 network
being used with the br-vlan devices. If no additional network interface is being used with the ``br-vlan`` devices. If no additional network interface is
available, a veth pair plugged into the br-vlan bridge can provide the needed available, a veth pair plugged into the ``br-vlan`` bridge can provide the
interface. necessary interface.
Example creating a veth-pair within an existing bridge The following is an example of creating a ``veth-pair`` within an existing bridge:
.. code-block:: text .. code-block:: text
# Create veth pair, don't bomb if already exists # Create veth pair, do not abort if already exists
pre-up ip link add br-vlan-veth type veth peer name PHYSICAL_NETWORK_INTERFACE || true pre-up ip link add br-vlan-veth type veth peer name PHYSICAL_NETWORK_INTERFACE || true
# Set both ends UP # Set both ends UP
pre-up ip link set br-vlan-veth up pre-up ip link set br-vlan-veth up

92
doc/source/install-guide/configure-nova.rst
View File

@ -1,44 +1,45 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide `Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring the Compute (Nova) Service (optional) Configuring the Compute (nova) service (optional)
------------------------------------------------- =================================================
The compute service (nova) handles the creation of virtual machines within an The Compute service (nova) handles the creation of virtual machines within an
OpenStack environment. Many of the default options used by OpenStack-Ansible OpenStack environment. Many of the default options used by OpenStack-Ansible
are found within `defaults/main.yml` within the nova role. are found within ``defaults/main.yml`` within the nova role.
Availability zones Availability zones
~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~
Deployers with multiple availability zones (AZ's) can set the Deployers with multiple availability zones can set the
``nova_default_schedule_zone`` Ansible variable to specify an AZ to use for ``nova_default_schedule_zone`` Ansible variable to specify an availability zone
instance build requests where an AZ is not provided. This could be useful in for new requests. This is useful in environments with different types
environments with different types of hypervisors where builds are sent to of hypervisors, where builds are sent to certain hardware types based on
certain hardware types based on their resource requirements. their resource requirements.
For example, if a deployer has some servers with spinning hard disks and others For example, if you have servers running on two racks without sharing the PDU.
with SSDs, they can set the default AZ to one that uses only spinning disks (to These two racks can be grouped into two availability zones.
save costs). To build an instance using SSDs, users must select an AZ that When one rack loses power, the other one still works. By spreading
includes SSDs and provide that AZ in their instance build request. your containers onto the two racks (availability zones), you will
improve your service availability.
Block device tuning for Ceph (RBD) Block device tuning for Ceph (RBD)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When Ceph is enabled and ``nova_libvirt_images_rbd_pool`` is defined, two Enabling Ceph and defining ``nova_libvirt_images_rbd_pool`` changes two
libvirt configurations will be changed by default: libvirt configurations by default:
* hw_disk_discard: ``unmap`` * hw_disk_discard: ``unmap``
* disk_cachemodes: ``network=writeback`` * disk_cachemodes: ``network=writeback``
Setting ``hw_disk_discard`` to ``unmap`` in libvirt will enable Setting ``hw_disk_discard`` to ``unmap`` in libvirt enables
discard (sometimes called TRIM) support for the underlying block device. This discard (sometimes called TRIM) support for the underlying block device. This
allows for unused blocks to be reclaimed on the underlying disks. allows reclaiming of unused blocks on the underlying disks.
Setting ``disk_cachemodes`` to ``network=writeback`` allows data to be written Setting ``disk_cachemodes`` to ``network=writeback`` allows data to be written
into a cache on each change, but those changes are flushed to disk at a regular into a cache on each change, but those changes are flushed to disk at a regular
interval. This can increase write performance on Ceph block devices. interval. This can increase write performance on Ceph block devices.
Deployers have the option to customize these settings using two Ansible You have the option to customize these settings using two Ansible
variables (defaults shown here): variables (defaults shown here):
.. code-block:: yaml .. code-block:: yaml
@ -46,15 +47,13 @@ variables (defaults shown here):
nova_libvirt_hw_disk_discard: 'unmap' nova_libvirt_hw_disk_discard: 'unmap'
nova_libvirt_disk_cachemodes: 'network=writeback' nova_libvirt_disk_cachemodes: 'network=writeback'
Deployers can disable discard by setting ``nova_libvirt_hw_disk_discard`` to You can disable discard by setting ``nova_libvirt_hw_disk_discard`` to
``ignore``. The ``nova_libvirt_disk_cachemodes`` can be set to an empty ``ignore``. The ``nova_libvirt_disk_cachemodes`` can be set to an empty
string to disable ``network=writeback``. string to disable ``network=writeback``.
The following minimal example configuration sets nova to use the The following minimal example configuration sets nova to use the
``ephemeral-vms`` ceph pool.The example uses cephx authentication, and ``ephemeral-vms`` Ceph pool. The following example uses cephx authentication, and
requires an existing ``cinder`` account for the ``ephemeral-vms`` pool. requires an existing ``cinder`` account for the ``ephemeral-vms`` pool:
.. code-block:: console .. code-block:: console
@ -65,33 +64,29 @@ requires an existing ``cinder`` account for the ``ephemeral-vms`` pool.
- 172.29.244.153 - 172.29.244.153
If you have a different ceph username for the pool, you can use it as If you have a different Ceph username for the pool, use it as:
.. code-block:: console .. code-block:: console
cinder_ceph_client: <ceph-username> cinder_ceph_client: <ceph-username>
* The `Ceph documentation for OpenStack`_ has additional information about these settings. * The `Ceph documentation for OpenStack`_ has additional information about these settings.
* `OpenStack-Ansible and Ceph Working Example`_ * `OpenStack-Ansible and Ceph Working Example`_
.. _Ceph documentation for OpenStack: http://docs.ceph.com/docs/master/rbd/rbd-openstack/ .. _Ceph documentation for OpenStack: http://docs.ceph.com/docs/master/rbd/rbd-openstack/
.. _OpenStack-Ansible and Ceph Working Example: https://www.openstackfaq.com/openstack-ansible-ceph/ .. _OpenStack-Ansible and Ceph Working Example: https://www.openstackfaq.com/openstack-ansible-ceph/
Config drive
Config Drive
~~~~~~~~~~~~ ~~~~~~~~~~~~
By default, OpenStack-Ansible will not configure Nova to force config drives By default, OpenStack-Ansible does not configure nova to force config drives
to be provisioned with every instance that Nova builds. The metadata service to be provisioned with every instance that nova builds. The metadata service
provides configuration information that can be used by cloud-init inside the provides configuration information that is used by ``cloud-init`` inside the
instance. Config drives are only necessary when an instance doesn't have instance. Config drives are only necessary when an instance does not have
cloud-init installed or doesn't have support for handling metadata. ``cloud-init`` installed or does not have support for handling metadata.
A deployer can set an Ansible variable to force config drives to be deployed A deployer can set an Ansible variable to force config drives to be deployed
with every virtual machine: with every virtual machine:
@ -101,8 +96,8 @@ with every virtual machine:
nova_force_config_drive: True nova_force_config_drive: True
Certain formats of config drives can prevent instances from migrating properly Certain formats of config drives can prevent instances from migrating properly
between hypervisors. If a deployer needs forced config drives and the ability between hypervisors. If you need forced config drives and the ability
to migrate instances, the config drive format should be set to ``vfat`` using to migrate instances, set the config drive format to ``vfat`` using
the ``nova_nova_conf_overrides`` variable: the ``nova_nova_conf_overrides`` variable:
.. code-block:: yaml .. code-block:: yaml
@ -112,7 +107,7 @@ the ``nova_nova_conf_overrides`` variable:
config_drive_format: vfat config_drive_format: vfat
force_config_drive: True force_config_drive: True
Libvirtd Connectivity and Authentication Libvirtd connectivity and authentication
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
By default, OpenStack-Ansible configures the libvirt daemon in the following By default, OpenStack-Ansible configures the libvirt daemon in the following
@ -122,8 +117,7 @@ way:
* TCP plaintext connections are disabled * TCP plaintext connections are disabled
* Authentication over TCP connections uses SASL * Authentication over TCP connections uses SASL
Deployers can customize these settings using the Ansible variables shown You can customize these settings using the following Ansible variables:
below:
.. code-block:: yaml .. code-block:: yaml
@ -139,8 +133,8 @@ below:
Multipath Multipath
~~~~~~~~~ ~~~~~~~~~
Nova supports multipath for iSCSI-based storage. Deployers can enable Nova supports multipath for iSCSI-based storage. Enable multipath support in
multipath support in nova through a configuration override: nova through a configuration override:
.. code-block:: yaml .. code-block:: yaml
@ -151,13 +145,13 @@ multipath support in nova through a configuration override:
Shared storage and synchronized UID/GID Shared storage and synchronized UID/GID
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Deployers can specify a custom UID for the nova user and GID for the nova group Specify a custom UID for the nova user and GID for the nova group
to ensure they are identical on each host. This is helpful when using shared to ensure they are identical on each host. This is helpful when using shared
storage on compute nodes because it allows instances to migrate without storage on Compute nodes because it allows instances to migrate without
filesystem ownership failures. filesystem ownership failures.
By default, Ansible will create the nova user and group without specifying the By default, Ansible creates the nova user and group without specifying the
UID or GID. To specify custom values for the UID/GID, set the following UID or GID. To specify custom values for the UID or GID, set the following
Ansible variables: Ansible variables:
.. code-block:: yaml .. code-block:: yaml
@ -165,9 +159,11 @@ Ansible variables:
nova_system_user_uid = <specify a UID> nova_system_user_uid = <specify a UID>
nova_system_group_gid = <specify a GID> nova_system_group_gid = <specify a GID>
.. warning:: Setting this value **after** deploying an environment with .. warning::
Setting this value after deploying an environment with
OpenStack-Ansible can cause failures, errors, and general instability. These OpenStack-Ansible can cause failures, errors, and general instability. These
values should only be set once **before** deploying an OpenStack environment values should only be set once before deploying an OpenStack environment
and then never changed. and then never changed.
-------------- --------------