7ebd4a7914
We never used that faile anywhere in the inventory generation process, except saving mapping of hostnames to container_address. At the same time we never stored extra IPs there and as of today we can simplify workflow by simply dropping that file. Change-Id: Id8c4f6512bc913b2480106dedfa2e457c4776ae7
218 lines
6.5 KiB
ReStructuredText
218 lines
6.5 KiB
ReStructuredText
.. _configuring-inventory:
|
|
|
|
Configuring the inventory
|
|
=========================
|
|
|
|
In this chapter, you can find the information on how to configure
|
|
the openstack-ansible dynamic inventory to your needs.
|
|
|
|
Introduction
|
|
~~~~~~~~~~~~
|
|
|
|
Common OpenStack services and their configuration are defined by
|
|
OpenStack-Ansible in the
|
|
``/etc/openstack_deploy/openstack_user_config.yml`` settings file.
|
|
|
|
Additional services should be defined with a YAML file in
|
|
``/etc/openstack_deploy/conf.d``, in order to manage file size.
|
|
|
|
The ``/etc/openstack_deploy/env.d`` directory sources all YAML files into the
|
|
deployed environment, allowing a deployer to define additional group mappings.
|
|
This directory is used to extend the environment skeleton, or modify the
|
|
defaults defined in the ``inventory/env.d`` directory.
|
|
|
|
To understand how the dynamic inventory works, see
|
|
:ref:`inventory-in-depth`.
|
|
|
|
.. warning::
|
|
|
|
Never edit or delete the file
|
|
``/etc/openstack_deploy/openstack_inventory.json``. This can lead to
|
|
problems with the inventory: existng hosts and containers will be unmanaged
|
|
and new ones will be generated instead, breaking your existing deployment.
|
|
|
|
Configuration constraints
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Group memberships
|
|
-----------------
|
|
|
|
When adding groups, keep the following in mind:
|
|
|
|
* A group can contain hosts
|
|
* A group can contain child groups
|
|
|
|
However, groups cannot contain child groups and hosts.
|
|
|
|
The lxc_hosts Group
|
|
-------------------
|
|
|
|
When the dynamic inventory script creates a container name, the host on
|
|
which the container resides is added to the ``lxc_hosts`` inventory group.
|
|
|
|
Using this name for a group in the configuration will result in a runtime
|
|
error.
|
|
|
|
Deploying directly on hosts
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
To deploy a component directly on the host instead of within a container, set
|
|
the ``is_metal`` property to ``true`` for the container group in the
|
|
``container_skel`` section in the appropriate file.
|
|
|
|
The use of ``container_vars`` and mapping from container groups to host groups
|
|
is the same for a service deployed directly onto the host.
|
|
|
|
You can also use the ``no_containers`` option to specify a host that will have
|
|
all services deployed on metal inside of it.
|
|
|
|
.. note::
|
|
|
|
The ``cinder-volume`` component is deployed directly on the host by
|
|
default. See the ``env.d/cinder.yml`` file for this example.
|
|
|
|
Example: Running all controllers on metal
|
|
-----------------------------------------
|
|
For example, if you'd like to run all your controllers on metal, you would
|
|
have the following inside your ``openstack_user_config.yml``.
|
|
|
|
.. code-block:: yaml
|
|
|
|
infra_hosts:
|
|
infra1:
|
|
ip: 172.39.123.11
|
|
no_containers: true
|
|
infra2:
|
|
ip: 172.39.123.12
|
|
no_containers: true
|
|
infra3:
|
|
ip: 172.39.123.13
|
|
no_containers: true
|
|
|
|
Example: Running galera on dedicated hosts
|
|
------------------------------------------
|
|
|
|
For example, to run Galera directly on dedicated hosts, you would perform the
|
|
following steps:
|
|
|
|
#. Modify the ``container_skel`` section of the ``env.d/galera.yml`` file.
|
|
For example:
|
|
|
|
.. code-block:: yaml
|
|
|
|
container_skel:
|
|
galera_container:
|
|
belongs_to:
|
|
- db_containers
|
|
contains:
|
|
- galera
|
|
properties:
|
|
is_metal: true
|
|
|
|
.. note::
|
|
|
|
To deploy within containers on these dedicated hosts, omit the
|
|
``is_metal: true`` property.
|
|
|
|
#. Assign the ``db_containers`` container group (from the preceding step) to a
|
|
host group by providing a ``physical_skel`` section for the host group
|
|
in a new or existing file, such as ``env.d/galera.yml``.
|
|
For example:
|
|
|
|
.. code-block:: yaml
|
|
|
|
physical_skel:
|
|
db_containers:
|
|
belongs_to:
|
|
- all_containers
|
|
db_hosts:
|
|
belongs_to:
|
|
- hosts
|
|
|
|
#. Define the host group (``db_hosts``) in a ``conf.d/`` file (such as
|
|
``galera.yml``). For example:
|
|
|
|
.. code-block:: yaml
|
|
|
|
db_hosts:
|
|
db-host1:
|
|
ip: 172.39.123.11
|
|
db-host2:
|
|
ip: 172.39.123.12
|
|
db-host3:
|
|
ip: 172.39.123.13
|
|
|
|
.. note::
|
|
|
|
Each of the custom group names in this example (``db_containers``
|
|
and ``db_hosts``) are arbitrary. Choose your own group names,
|
|
but ensure the references are consistent among all relevant files.
|
|
|
|
.. _affinity:
|
|
|
|
Deploying 0 (or more than one) of component type per host
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
When OpenStack-Ansible generates its dynamic inventory, the affinity
|
|
setting determines how many containers of a similar type are deployed on a
|
|
single physical host.
|
|
|
|
Using ``shared-infra_hosts`` as an example, consider this
|
|
``openstack_user_config.yml`` configuration:
|
|
|
|
.. code-block:: yaml
|
|
|
|
shared-infra_hosts:
|
|
infra1:
|
|
ip: 172.29.236.101
|
|
infra2:
|
|
ip: 172.29.236.102
|
|
infra3:
|
|
ip: 172.29.236.103
|
|
|
|
Three hosts are assigned to the `shared-infra_hosts` group,
|
|
OpenStack-Ansible ensures that each host runs a single database container,
|
|
a single Memcached container, and a single RabbitMQ container. Each host has
|
|
an affinity of 1 by default, which means that each host runs one of each
|
|
container type.
|
|
|
|
If you are deploying a stand-alone Object Storage (swift) environment,
|
|
you can skip the deployment of RabbitMQ. If you use this configuration,
|
|
your ``openstack_user_config.yml`` file would look as follows:
|
|
|
|
.. code-block:: yaml
|
|
|
|
shared-infra_hosts:
|
|
infra1:
|
|
affinity:
|
|
rabbit_mq_container: 0
|
|
ip: 172.29.236.101
|
|
infra2:
|
|
affinity:
|
|
rabbit_mq_container: 0
|
|
ip: 172.29.236.102
|
|
infra3:
|
|
affinity:
|
|
rabbit_mq_container: 0
|
|
ip: 172.29.236.103
|
|
|
|
This configuration deploys a Memcached container and a database container
|
|
on each host, but no RabbitMQ containers.
|
|
|
|
Omit a service or component from the deployment
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
To omit a component from a deployment, you can use one of several options:
|
|
|
|
- Remove the ``physical_skel`` link between the container group and
|
|
the host group by deleting the related file located in the ``env.d/``
|
|
directory.
|
|
- Do not run the playbook that installs the component.
|
|
Unless you specify the component to run directly on a host by using the
|
|
``is_metal`` property, a container is created for this component.
|
|
- Adjust the :ref:`affinity`
|
|
to 0 for the host group. Similar to the second option listed here, Unless
|
|
you specify the component to run directly on a host by using the ``is_metal``
|
|
property, a container is created for this component.
|
|
|