[Docs] Backport Master structure
This is backport combining the documentation changes applied master according to the queens blueprint "docs-improvements": * [Docs] Flatten out monitoring (cherry picked from commitebdd5759b1
) * [Docs] Move upgrade guides into ops (cherry picked from commit56194bcb5a
) * [Docs] Merge advanced configuration into reference (cherry picked from commitba7e064ef9
) * [Docs] Uniform landing text (cherry picked from commit134ec81016
) * [Docs] Move AIO to first scenario (cherry picked from commitdc8d6256ce
) * [Docs] Include test scenario as a new user story (cherry picked from commit3d76d5e2e2
) * [Docs] Fix references (cherry picked from commit1d47028911
) * [Docs] Move more examples to user guide (cherry picked from commit73c45a8108
) * [Docs] Move Ceph example to user guides (cherry picked from commitd27e329a5a
) * [Docs] Move network architecture into reference (cherry picked from commit99ca16e85e
) * [Docs] Centralize Inventory documentation (cherry picked from commiteb89fa513a
) * [Docs] Move limited connectivity to user guide (cherry picked from commitb6eb92beca
) * [Docs] Migrate security into user guide (cherry picked from commitf1a7525570
) * [Docs] Guide users more (cherry picked from commit99f4f17751
) * [Docs] Add explicit warnings on common mistake (cherry picked from commit41bd98385b
) Change-Id: I4b39f2a9f33eff7d0433a98a085cf4fd05cef75e
@ -49,7 +49,7 @@ https://git.openstack.org/cgit/openstack/openstack-ansible-<ROLENAME>.
|
|||||||
.. _official OpenStack project: https://governance.openstack.org/reference/projects/index.html
|
.. _official OpenStack project: https://governance.openstack.org/reference/projects/index.html
|
||||||
.. _Home Page: https://governance.openstack.org/reference/projects/openstackansible.html
|
.. _Home Page: https://governance.openstack.org/reference/projects/openstackansible.html
|
||||||
.. _Deployment Guide: https://docs.openstack.org/project-deploy-guide/openstack-ansible/latest
|
.. _Deployment Guide: https://docs.openstack.org/project-deploy-guide/openstack-ansible/latest
|
||||||
.. _Quick Start: https://docs.openstack.org/openstack-ansible/latest/contributor/quickstart-aio.html
|
.. _Quick Start: https://docs.openstack.org/openstack-ansible/latest/user/aio/quickstart.html
|
||||||
.. _Developer Documentation: https://docs.openstack.org/openstack-ansible/latest/contributor/index.html
|
.. _Developer Documentation: https://docs.openstack.org/openstack-ansible/latest/contributor/index.html
|
||||||
.. _Source: https://git.openstack.org/cgit/openstack/openstack-ansible
|
.. _Source: https://git.openstack.org/cgit/openstack/openstack-ansible
|
||||||
.. _OpenStack Mailing Lists: http://lists.openstack.org/
|
.. _OpenStack Mailing Lists: http://lists.openstack.org/
|
||||||
|
@ -1,50 +0,0 @@
|
|||||||
========
|
|
||||||
Affinity
|
|
||||||
========
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
@ -1,12 +0,0 @@
|
|||||||
==================================
|
|
||||||
Appendix I: Advanced configuration
|
|
||||||
==================================
|
|
||||||
|
|
||||||
.. TODO: include intro on what advanced configuration is, whether it’s required
|
|
||||||
or optional, and when someone should do it
|
|
||||||
|
|
||||||
.. toctree::
|
|
||||||
:maxdepth: 2
|
|
||||||
|
|
||||||
app-advanced-config-override
|
|
||||||
app-advanced-config-affinity
|
|
@ -1,270 +0,0 @@
|
|||||||
===========================================
|
|
||||||
Overriding OpenStack configuration defaults
|
|
||||||
===========================================
|
|
||||||
|
|
||||||
OpenStack has many configuration options available in ``.conf`` files
|
|
||||||
(in a standard ``INI`` file format),
|
|
||||||
policy files (in a standard ``JSON`` format) and ``YAML`` files.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
``YAML`` files are only in the ceilometer project at this time.
|
|
||||||
|
|
||||||
OpenStack-Ansible enables you to reference any options in the
|
|
||||||
`OpenStack Configuration Reference`_ through the use of a simple set of
|
|
||||||
configuration entries in the ``/etc/openstack_deploy/user_variables.yml``.
|
|
||||||
|
|
||||||
This section describes how to use the configuration entries in the
|
|
||||||
``/etc/openstack_deploy/user_variables.yml`` file to override default
|
|
||||||
configuration settings. For more information, see the
|
|
||||||
:dev_docs:`Setting overrides in configuration files
|
|
||||||
<extending.html#setting-overrides-in-configuration-files>` section in the
|
|
||||||
developer documentation.
|
|
||||||
|
|
||||||
.. _OpenStack Configuration Reference: http://docs.openstack.org/draft/config-reference/
|
|
||||||
|
|
||||||
Overriding .conf files
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
Most often, overrides are implemented for the ``<service>.conf`` files
|
|
||||||
(for example, ``nova.conf``). These files use a standard INI file format.
|
|
||||||
|
|
||||||
For example, you might want to add the following parameters to the
|
|
||||||
``nova.conf`` file:
|
|
||||||
|
|
||||||
.. code-block:: ini
|
|
||||||
|
|
||||||
[DEFAULT]
|
|
||||||
remove_unused_original_minimum_age_seconds = 43200
|
|
||||||
|
|
||||||
[libvirt]
|
|
||||||
cpu_mode = host-model
|
|
||||||
disk_cachemodes = file=directsync,block=none
|
|
||||||
|
|
||||||
[database]
|
|
||||||
idle_timeout = 300
|
|
||||||
max_pool_size = 10
|
|
||||||
|
|
||||||
To do this, you use the following configuration entry in the
|
|
||||||
``/etc/openstack_deploy/user_variables.yml`` file:
|
|
||||||
|
|
||||||
.. code-block:: yaml
|
|
||||||
|
|
||||||
nova_nova_conf_overrides:
|
|
||||||
DEFAULT:
|
|
||||||
remove_unused_original_minimum_age_seconds: 43200
|
|
||||||
libvirt:
|
|
||||||
cpu_mode: host-model
|
|
||||||
disk_cachemodes: file=directsync,block=none
|
|
||||||
database:
|
|
||||||
idle_timeout: 300
|
|
||||||
max_pool_size: 10
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
The general format for the variable names used for overrides is
|
|
||||||
``<service>_<filename>_<file extension>_overrides``. For example, the variable
|
|
||||||
name used in these examples to add parameters to the ``nova.conf`` file is
|
|
||||||
``nova_nova_conf_overrides``.
|
|
||||||
|
|
||||||
You can also apply overrides on a per-host basis with the following
|
|
||||||
configuration in the ``/etc/openstack_deploy/openstack_user_config.yml``
|
|
||||||
file:
|
|
||||||
|
|
||||||
.. code-block:: yaml
|
|
||||||
|
|
||||||
compute_hosts:
|
|
||||||
900089-compute001:
|
|
||||||
ip: 192.0.2.10
|
|
||||||
host_vars:
|
|
||||||
nova_nova_conf_overrides:
|
|
||||||
DEFAULT:
|
|
||||||
remove_unused_original_minimum_age_seconds: 43200
|
|
||||||
libvirt:
|
|
||||||
cpu_mode: host-model
|
|
||||||
disk_cachemodes: file=directsync,block=none
|
|
||||||
database:
|
|
||||||
idle_timeout: 300
|
|
||||||
max_pool_size: 10
|
|
||||||
|
|
||||||
Use this method for any files with the ``INI`` format for in OpenStack projects
|
|
||||||
deployed in OpenStack-Ansible.
|
|
||||||
|
|
||||||
Overriding .json files
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
To implement access controls that are different from the ones in a standard
|
|
||||||
OpenStack environment, you can adjust the default policies applied by services.
|
|
||||||
Policy files are in a ``JSON`` format.
|
|
||||||
|
|
||||||
For example, you might want to add the following policy in the ``policy.json``
|
|
||||||
file for the Identity service (keystone):
|
|
||||||
|
|
||||||
.. code-block:: json
|
|
||||||
|
|
||||||
{
|
|
||||||
"identity:foo": "rule:admin_required",
|
|
||||||
"identity:bar": "rule:admin_required"
|
|
||||||
}
|
|
||||||
|
|
||||||
To do this, you use the following configuration entry in the
|
|
||||||
``/etc/openstack_deploy/user_variables.yml`` file:
|
|
||||||
|
|
||||||
.. code-block:: yaml
|
|
||||||
|
|
||||||
keystone_policy_overrides:
|
|
||||||
identity:foo: "rule:admin_required"
|
|
||||||
identity:bar: "rule:admin_required"
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
The general format for the variable names used for overrides is
|
|
||||||
``<service>_policy_overrides``. For example, the variable name used in this
|
|
||||||
example to add a policy to the Identity service (keystone) ``policy.json`` file
|
|
||||||
is ``keystone_policy_overrides``.
|
|
||||||
|
|
||||||
Use this method for any files with the ``JSON`` format in OpenStack projects
|
|
||||||
deployed in OpenStack-Ansible.
|
|
||||||
|
|
||||||
To assist you in finding the appropriate variable name to use for
|
|
||||||
overrides, the general format for the variable name is
|
|
||||||
``<service>_policy_overrides``.
|
|
||||||
|
|
||||||
Overriding .yml files
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
You can override ``.yml`` file values by supplying replacement YAML content.
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
All default YAML file content is completely overwritten by the overrides,
|
|
||||||
so the entire YAML source (both the existing content and your changes)
|
|
||||||
must be provided.
|
|
||||||
|
|
||||||
For example, you might want to define a meter exclusion for all hardware
|
|
||||||
items in the default content of the ``pipeline.yml`` file for the
|
|
||||||
Telemetry service (ceilometer):
|
|
||||||
|
|
||||||
.. code-block:: yaml
|
|
||||||
|
|
||||||
sources:
|
|
||||||
- name: meter_source
|
|
||||||
interval: 600
|
|
||||||
meters:
|
|
||||||
- "!hardware.*"
|
|
||||||
sinks:
|
|
||||||
- meter_sink
|
|
||||||
- name: foo_source
|
|
||||||
value: foo
|
|
||||||
|
|
||||||
To do this, you use the following configuration entry in the
|
|
||||||
``/etc/openstack_deploy/user_variables.yml`` file:
|
|
||||||
|
|
||||||
.. code-block:: yaml
|
|
||||||
|
|
||||||
ceilometer_pipeline_yaml_overrides:
|
|
||||||
sources:
|
|
||||||
- name: meter_source
|
|
||||||
interval: 600
|
|
||||||
meters:
|
|
||||||
- "!hardware.*"
|
|
||||||
sinks:
|
|
||||||
- meter_sink
|
|
||||||
- name: source_foo
|
|
||||||
value: foo
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
The general format for the variable names used for overrides is
|
|
||||||
``<service>_<filename>_<file extension>_overrides``. For example, the variable
|
|
||||||
name used in this example to define a meter exclusion in the ``pipeline.yml`` file
|
|
||||||
for the Telemetry service (ceilometer) is ``ceilometer_pipeline_yaml_overrides``.
|
|
||||||
|
|
||||||
Currently available overrides
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
The following override variables are available.
|
|
||||||
|
|
||||||
Galera:
|
|
||||||
* galera_client_my_cnf_overrides
|
|
||||||
* galera_my_cnf_overrides
|
|
||||||
* galera_cluster_cnf_overrides
|
|
||||||
* galera_debian_cnf_overrides
|
|
||||||
|
|
||||||
Telemetry service (ceilometer):
|
|
||||||
* ceilometer_policy_overrides
|
|
||||||
* ceilometer_ceilometer_conf_overrides
|
|
||||||
* ceilometer_event_definitions_yaml_overrides
|
|
||||||
* ceilometer_event_pipeline_yaml_overrides
|
|
||||||
* ceilometer_pipeline_yaml_overrides
|
|
||||||
|
|
||||||
Block Storage (cinder):
|
|
||||||
* cinder_policy_overrides
|
|
||||||
* cinder_rootwrap_conf_overrides
|
|
||||||
* cinder_api_paste_ini_overrides
|
|
||||||
* cinder_cinder_conf_overrides
|
|
||||||
|
|
||||||
Image service (glance):
|
|
||||||
* glance_glance_api_paste_ini_overrides
|
|
||||||
* glance_glance_api_conf_overrides
|
|
||||||
* glance_glance_cache_conf_overrides
|
|
||||||
* glance_glance_manage_conf_overrides
|
|
||||||
* glance_glance_registry_paste_ini_overrides
|
|
||||||
* glance_glance_registry_conf_overrides
|
|
||||||
* glance_glance_scrubber_conf_overrides
|
|
||||||
* glance_glance_scheme_json_overrides
|
|
||||||
* glance_policy_overrides
|
|
||||||
|
|
||||||
Orchestration service (heat):
|
|
||||||
* heat_heat_conf_overrides
|
|
||||||
* heat_api_paste_ini_overrides
|
|
||||||
* heat_default_yaml_overrides
|
|
||||||
* heat_aws_rds_dbinstance_yaml_overrides
|
|
||||||
* heat_policy_overrides
|
|
||||||
|
|
||||||
Identity service (keystone):
|
|
||||||
* keystone_keystone_conf_overrides
|
|
||||||
* keystone_keystone_default_conf_overrides
|
|
||||||
* keystone_keystone_paste_ini_overrides
|
|
||||||
* keystone_policy_overrides
|
|
||||||
|
|
||||||
Networking service (neutron):
|
|
||||||
* neutron_neutron_conf_overrides
|
|
||||||
* neutron_ml2_conf_ini_overrides
|
|
||||||
* neutron_dhcp_agent_ini_overrides
|
|
||||||
* neutron_api_paste_ini_overrides
|
|
||||||
* neutron_rootwrap_conf_overrides
|
|
||||||
* neutron_policy_overrides
|
|
||||||
* neutron_dnsmasq_neutron_conf_overrides
|
|
||||||
* neutron_l3_agent_ini_overrides
|
|
||||||
* neutron_metadata_agent_ini_overrides
|
|
||||||
* neutron_metering_agent_ini_overrides
|
|
||||||
|
|
||||||
Compute service (nova):
|
|
||||||
* nova_nova_conf_overrides
|
|
||||||
* nova_rootwrap_conf_overrides
|
|
||||||
* nova_api_paste_ini_overrides
|
|
||||||
* nova_policy_overrides
|
|
||||||
|
|
||||||
Object Storage service (swift):
|
|
||||||
* swift_swift_conf_overrides
|
|
||||||
* swift_swift_dispersion_conf_overrides
|
|
||||||
* swift_proxy_server_conf_overrides
|
|
||||||
* swift_account_server_conf_overrides
|
|
||||||
* swift_account_server_replicator_conf_overrides
|
|
||||||
* swift_container_server_conf_overrides
|
|
||||||
* swift_container_server_replicator_conf_overrides
|
|
||||||
* swift_object_server_conf_overrides
|
|
||||||
* swift_object_server_replicator_conf_overrides
|
|
||||||
|
|
||||||
Tempest:
|
|
||||||
* tempest_tempest_conf_overrides
|
|
||||||
|
|
||||||
pip:
|
|
||||||
* pip_global_conf_overrides
|
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
Possible additional overrides can be found in the "Tunable Section"
|
|
||||||
of each role's ``main.yml`` file, such as
|
|
||||||
``/etc/ansible/roles/role_name/defaults/main.yml``.
|
|
@ -1,13 +0,0 @@
|
|||||||
====================================
|
|
||||||
Appendix J: Ceph-Ansible integration
|
|
||||||
====================================
|
|
||||||
|
|
||||||
OpenStack-Ansible allows `Ceph storage <https://ceph.com>`_ cluster integration
|
|
||||||
using the roles maintained by the `Ceph-Ansible`_ project. Deployers can
|
|
||||||
enable the ``ceph-install`` playbook by adding hosts to the
|
|
||||||
``ceph-mon_hosts`` and ``ceph-osd_hosts`` groups in
|
|
||||||
``openstack_user_config.yml``, and then configuring `Ceph-Ansible specific vars
|
|
||||||
<https://github.com/ceph/ceph-ansible/blob/master/group_vars/all.yml.sample>`_
|
|
||||||
in the OpenStack-Ansible ``user_variables.yml`` file.
|
|
||||||
|
|
||||||
.. _Ceph-Ansible: https://github.com/ceph/ceph-ansible/
|
|
@ -1,6 +1,6 @@
|
|||||||
================================
|
====================
|
||||||
Appendix K: Additional resources
|
Additional resources
|
||||||
================================
|
====================
|
||||||
|
|
||||||
Ansible resources:
|
Ansible resources:
|
||||||
|
|
||||||
|
@ -5,15 +5,4 @@ Appendices
|
|||||||
.. toctree::
|
.. toctree::
|
||||||
:maxdepth: 2
|
:maxdepth: 2
|
||||||
|
|
||||||
app-config-test.rst
|
|
||||||
app-config-prod.rst
|
|
||||||
app-config-pod.rst
|
|
||||||
app-config-prod-ceph.rst
|
|
||||||
app-custom-layouts.rst
|
|
||||||
app-security.rst
|
|
||||||
app-networking.rst
|
|
||||||
app-limited-connectivity.rst
|
|
||||||
app-advanced-config-sslcertificates
|
|
||||||
app-advanced-config-options.rst
|
|
||||||
app-ceph.rst
|
|
||||||
app-resources.rst
|
app-resources.rst
|
||||||
|
@ -335,7 +335,7 @@ if watermark == "":
|
|||||||
dev_branch_link_name = ""
|
dev_branch_link_name = ""
|
||||||
|
|
||||||
deploy_guide_prefix = "http://docs.openstack.org/project-deploy-guide/openstack-ansible/{}/%s".format(deploy_branch_link_name)
|
deploy_guide_prefix = "http://docs.openstack.org/project-deploy-guide/openstack-ansible/{}/%s".format(deploy_branch_link_name)
|
||||||
dev_docs_prefix = "http://docs.openstack.org/openstack-ansible/{}%s".format(dev_branch_link_name)
|
dev_docs_prefix = "http://docs.openstack.org/openstack-ansible/{}/%s".format(deploy_branch_link_name)
|
||||||
role_docs_prefix = "http://docs.openstack.org/openstack-ansible-%s/{}".format(dev_branch_link_name)
|
role_docs_prefix = "http://docs.openstack.org/openstack-ansible-%s/{}".format(dev_branch_link_name)
|
||||||
|
|
||||||
extlinks = {'deploy_guide': (deploy_guide_prefix, ''),
|
extlinks = {'deploy_guide': (deploy_guide_prefix, ''),
|
||||||
|
@ -39,8 +39,9 @@ host.
|
|||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
The file is heavily commented with details about the various options.
|
This file is heavily commented with details about the various options.
|
||||||
See :ref:`openstack-user-config-reference` for more details.
|
See our :dev_docs:`User Guide <user/index.html>` and
|
||||||
|
:dev_docs:`Reference Guide <reference/index.html>` for more details.
|
||||||
|
|
||||||
The configuration in the ``openstack_user_config.yml`` file defines which hosts
|
The configuration in the ``openstack_user_config.yml`` file defines which hosts
|
||||||
run the containers and services deployed by OpenStack-Ansible. For
|
run the containers and services deployed by OpenStack-Ansible. For
|
||||||
@ -55,16 +56,12 @@ individually in the example file as they are contained in the os-infra hosts.
|
|||||||
You can specify image-hosts or dashboard-hosts if you want to scale out in a
|
You can specify image-hosts or dashboard-hosts if you want to scale out in a
|
||||||
specific manner.
|
specific manner.
|
||||||
|
|
||||||
For examples, please see :ref:`test-environment-config`,
|
For examples, please see our :dev_docs:`User Guides <user/index.html>`
|
||||||
:ref:`production-environment-config`, and :ref:`pod-environment-config`
|
|
||||||
|
|
||||||
For details about how the inventory is generated from the environment
|
For details about how the inventory is generated, from the environment
|
||||||
configuration, see
|
configuration and the variable precedence, see our
|
||||||
`developer-inventory <https://docs.openstack.org/openstack-ansible/latest/reference/index.html>`_.
|
:dev_docs:`Reference Guide <reference/index.html>` under the inventory
|
||||||
|
section.
|
||||||
For details about how variable precedence works, and how to override
|
|
||||||
group vars, see
|
|
||||||
`developer-inventory-and-vars <https://docs.openstack.org/openstack-ansible/latest/contributor/inventory-and-vars.html>`_.
|
|
||||||
|
|
||||||
Installing additional services
|
Installing additional services
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
@ -81,6 +78,14 @@ OpenStack-Ansible has many options that you can use for the advanced
|
|||||||
configuration of services. Each role's documentation provides information
|
configuration of services. Each role's documentation provides information
|
||||||
about the available options.
|
about the available options.
|
||||||
|
|
||||||
|
.. important::
|
||||||
|
|
||||||
|
This step is essential to tailoring OpenStack-Ansible to your needs
|
||||||
|
and is generally overlooked by new deployers. Have a look at each
|
||||||
|
role documentation, user guides, and reference if you want a tailor
|
||||||
|
made cloud.
|
||||||
|
|
||||||
|
|
||||||
Infrastructure service roles
|
Infrastructure service roles
|
||||||
----------------------------
|
----------------------------
|
||||||
|
|
||||||
|
@ -154,7 +154,9 @@ Install the source and dependencies for the deployment host.
|
|||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
If you are installing with limited connectivity, please review
|
If you are installing with limited connectivity, please review
|
||||||
:ref:`limited-connectivity-appendix` before proceeding.
|
:dev_docs:`Installing with limited connectivity
|
||||||
|
<user/limited-connectivity/index.html>`
|
||||||
|
before proceeding.
|
||||||
|
|
||||||
#. Clone the latest stable release of the OpenStack-Ansible Git repository in
|
#. Clone the latest stable release of the OpenStack-Ansible Git repository in
|
||||||
the ``/opt/openstack-ansible`` directory:
|
the ``/opt/openstack-ansible`` directory:
|
||||||
|
@ -9,7 +9,7 @@ intended for deployers.
|
|||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
If you want to do a quick proof of concept of OpenStack, read the
|
If you want to do a quick proof of concept of OpenStack, read the
|
||||||
`All-In-One quickstart Guide <https://docs.openstack.org/openstack-ansible/latest/contributor/quickstart-aio.html>`_
|
`All-In-One quickstart Guide <https://docs.openstack.org/openstack-ansible/latest/user/aio/quickstart.html>`_
|
||||||
instead of this document. This document is a walkthrough of a deploy
|
instead of this document. This document is a walkthrough of a deploy
|
||||||
using OpenStack-Ansible, with all its configurability.
|
using OpenStack-Ansible, with all its configurability.
|
||||||
|
|
||||||
|
@ -5,14 +5,14 @@ Next steps
|
|||||||
Now that you have verified that your OpenStack cloud
|
Now that you have verified that your OpenStack cloud
|
||||||
is working, here is what you can do next:
|
is working, here is what you can do next:
|
||||||
|
|
||||||
Contribute to OpenStack-Ansible
|
|
||||||
===============================
|
|
||||||
|
|
||||||
If you want to contribute to OpenStack-Ansible, please
|
|
||||||
have a look at our `Contributors guide <https://docs.openstack.org/openstack-ansible/latest/contributor/index.html>`_.
|
|
||||||
|
|
||||||
|
|
||||||
Operate OpenStack-Ansible
|
Operate OpenStack-Ansible
|
||||||
=========================
|
=========================
|
||||||
|
|
||||||
Have a look at our `Operations guide <https://docs.openstack.org/openstack-ansible/latest/admin/index.html>`_.
|
Review our `Operations guide <https://docs.openstack.org/openstack-ansible/latest/admin/index.html>`_
|
||||||
|
to learn about verifying your environment in more detail, and creating your first networks, images, and instances.
|
||||||
|
|
||||||
|
Contribute to OpenStack-Ansible
|
||||||
|
===============================
|
||||||
|
|
||||||
|
Review our `Contributors guide <https://docs.openstack.org/openstack-ansible/latest/contributor/index.html>`_
|
||||||
|
to learn about contributing to OpenStack-Ansible.
|
@ -9,7 +9,9 @@ hosts requires manual configuration because it varies from one use case to
|
|||||||
another. This section describes the network configuration that must be
|
another. This section describes the network configuration that must be
|
||||||
implemented on all target hosts.
|
implemented on all target hosts.
|
||||||
|
|
||||||
For more information about how networking works, see :ref:`network-appendix`.
|
For more information about how networking works, see the
|
||||||
|
:dev_docs:`OpenStack-Ansible Reference Architecture, section Container
|
||||||
|
Networking <reference/architecture/index.html>`.
|
||||||
|
|
||||||
Host network bridges
|
Host network bridges
|
||||||
~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~
|
||||||
|
@ -23,7 +23,9 @@ The following table shows bridges that are to be configured on hosts.
|
|||||||
+-------------+-----------------------+-------------------------------------+
|
+-------------+-----------------------+-------------------------------------+
|
||||||
|
|
||||||
For a detailed reference of how the host and container networking is
|
For a detailed reference of how the host and container networking is
|
||||||
implemented, refer to :ref:`network-appendix`.
|
implemented, refer to
|
||||||
|
:dev_docs:`OpenStack-Ansible Reference Architecture, section Container
|
||||||
|
Networking <reference/architecture/index.html>`.
|
||||||
|
|
||||||
For use case examples, refer to :ref:`test-environment-config` and
|
For use case examples, refer to
|
||||||
:ref:`production-environment-config`.
|
:dev_docs:`User Guides <user/index.html>`.
|
||||||
|
@ -29,17 +29,11 @@ configuration and testing.
|
|||||||
|
|
||||||
# lxc-attach -n infra1_utility_container-161a4084
|
# lxc-attach -n infra1_utility_container-161a4084
|
||||||
|
|
||||||
#. Source the ``admin`` tenant credentials:
|
#. List your openstack users:
|
||||||
|
|
||||||
.. code-block:: console
|
.. code-block:: console
|
||||||
|
|
||||||
# source /root/openrc
|
# openstack user list --os-cloud=default
|
||||||
|
|
||||||
#. Run an OpenStack command that uses one or more APIs. For example:
|
|
||||||
|
|
||||||
.. code-block:: console
|
|
||||||
|
|
||||||
# openstack user list
|
|
||||||
+----------------------------------+--------------------+
|
+----------------------------------+--------------------+
|
||||||
| ID | Name |
|
| ID | Name |
|
||||||
+----------------------------------+--------------------+
|
+----------------------------------+--------------------+
|
||||||
@ -60,7 +54,7 @@ configuration and testing.
|
|||||||
+----------------------------------+--------------------+
|
+----------------------------------+--------------------+
|
||||||
|
|
||||||
Verifying the Dashboard (horizon)
|
Verifying the Dashboard (horizon)
|
||||||
---------------------------------
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
#. With a web browser, access the Dashboard by using the external load
|
#. With a web browser, access the Dashboard by using the external load
|
||||||
balancer IP address defined by the ``external_lb_vip_address`` option
|
balancer IP address defined by the ``external_lb_vip_address`` option
|
||||||
|
@ -1,3 +1,5 @@
|
|||||||
|
.. _backup-restore:
|
||||||
|
|
||||||
==============================
|
==============================
|
||||||
Back up and restore your cloud
|
Back up and restore your cloud
|
||||||
==============================
|
==============================
|
||||||
@ -26,4 +28,4 @@ Database backups and recovery
|
|||||||
MySQL data is available on the infrastructure nodes.
|
MySQL data is available on the infrastructure nodes.
|
||||||
You can recover databases, and rebuild the galera cluster.
|
You can recover databases, and rebuild the galera cluster.
|
||||||
For more information, see
|
For more information, see
|
||||||
:ref:`galera-cluster-maintenance`.
|
:ref:`galera-cluster-recovery`.
|
||||||
|
@ -5,15 +5,21 @@ Operations Guide
|
|||||||
This guide provides information about operating your OpenStack-Ansible
|
This guide provides information about operating your OpenStack-Ansible
|
||||||
deployment.
|
deployment.
|
||||||
|
|
||||||
For information how to deploy your OpenStack-Ansible cloud, refer to the
|
For information on how to deploy your OpenStack-Ansible cloud, refer to the
|
||||||
`Deployment Guide <https://docs.openstack.org/project-deploy-guide/openstack-ansible/latest/>`_.
|
:deploy_guide:`Deployment Guide <index.html>` for step-by-step
|
||||||
for step-by-step instructions on how to deploy the OpenStack packages and
|
instructions on how to deploy the OpenStack packages and
|
||||||
dependencies on your cloud using OpenStack-Ansible.
|
dependencies on your cloud using OpenStack-Ansible.
|
||||||
|
|
||||||
This guide is recommended for users of a successfully deployed
|
For user guides, see the :dev_docs:`User Guide <user/index.html>`.
|
||||||
OpenStack-Ansible cloud. This explains from basic operations such as
|
|
||||||
adding images, booting instances, and attaching volumes, to the
|
For information on how to contribute, extend or develop OpenStack-Ansible,
|
||||||
more complex operations like upgrading.
|
see the :dev_docs:`Contributors Guide <contributor/index.html>`.
|
||||||
|
|
||||||
|
For in-depth technical information, see the
|
||||||
|
:dev_docs:`OpenStack-Ansible Reference <reference/index.html>`.
|
||||||
|
|
||||||
|
This guide ranges from first operations to verify your deployment, to
|
||||||
|
the major upgrades procedures.
|
||||||
|
|
||||||
.. toctree::
|
.. toctree::
|
||||||
:maxdepth: 1
|
:maxdepth: 1
|
||||||
@ -22,7 +28,7 @@ more complex operations like upgrading.
|
|||||||
openstack-operations.rst
|
openstack-operations.rst
|
||||||
maintenance-tasks.rst
|
maintenance-tasks.rst
|
||||||
scale-environment.rst
|
scale-environment.rst
|
||||||
monitoring-systems.rst
|
monitor-environment/monitoring-systems.rst
|
||||||
backup-restore.rst
|
backup-restore.rst
|
||||||
troubleshooting.rst
|
troubleshooting.rst
|
||||||
upgrades/minor-updates.rst
|
upgrades/minor-updates.rst
|
||||||
|
@ -142,6 +142,8 @@ one of the nodes.
|
|||||||
wsrep_cluster_state_uuid 338b06b0-2948-11e4-9d06-bef42f6c52f1
|
wsrep_cluster_state_uuid 338b06b0-2948-11e4-9d06-bef42f6c52f1
|
||||||
wsrep_cluster_status Primary
|
wsrep_cluster_status Primary
|
||||||
|
|
||||||
|
.. _galera-cluster-recovery:
|
||||||
|
|
||||||
Galera cluster recovery
|
Galera cluster recovery
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
@ -1,11 +0,0 @@
|
|||||||
===========================
|
|
||||||
Monitoring your environment
|
|
||||||
===========================
|
|
||||||
|
|
||||||
This is a draft monitoring environment page for the proposed OpenStack-Ansible
|
|
||||||
operations guide.
|
|
||||||
|
|
||||||
.. toctree::
|
|
||||||
:maxdepth: 2
|
|
||||||
|
|
||||||
monitor-environment/monitoring-systems.rst
|
|
@ -1,6 +1,6 @@
|
|||||||
=======================================================
|
===========================
|
||||||
Integrate OpenStack-Ansible into your monitoring system
|
Monitoring your environment
|
||||||
=======================================================
|
===========================
|
||||||
|
|
||||||
This is a draft monitoring system page for the proposed OpenStack-Ansible
|
This is a draft monitoring system page for the proposed OpenStack-Ansible
|
||||||
operations guide.
|
operations guide.
|
||||||
|
@ -14,7 +14,7 @@ needed in an environment, it is possible to create additional nodes.
|
|||||||
.. warning::
|
.. warning::
|
||||||
|
|
||||||
Make sure you back up your current OpenStack environment
|
Make sure you back up your current OpenStack environment
|
||||||
before adding any new nodes. See :ref:`backing-up` for more
|
before adding any new nodes. See :ref:`backup-restore` for more
|
||||||
information.
|
information.
|
||||||
|
|
||||||
#. Add the node to the ``infra_hosts`` stanza of the
|
#. Add the node to the ``infra_hosts`` stanza of the
|
||||||
|
@ -1,6 +1,5 @@
|
|||||||
.. _upgrading-manually:
|
.. _upgrading-manually:
|
||||||
|
|
||||||
==================
|
|
||||||
Upgrading manually
|
Upgrading manually
|
||||||
==================
|
==================
|
||||||
|
|
@ -1,6 +1,5 @@
|
|||||||
.. _upgrading-by-using-a-script:
|
.. _upgrading-by-using-a-script:
|
||||||
|
|
||||||
===========================
|
|
||||||
Upgrading by using a script
|
Upgrading by using a script
|
||||||
===========================
|
===========================
|
||||||
|
|
||||||
@ -10,8 +9,8 @@ the code for migrating from |previous_release_formal_name| to
|
|||||||
|
|
||||||
.. warning::
|
.. warning::
|
||||||
|
|
||||||
The upgrade script is still under active development. Do *not* run it
|
The upgrade script is always under active development.
|
||||||
on a production environment at this time.
|
Test it on a development environment first.
|
||||||
|
|
||||||
Running the upgrade script
|
Running the upgrade script
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
@ -1,17 +1,18 @@
|
|||||||
========
|
==============
|
||||||
Overview
|
Major upgrades
|
||||||
========
|
==============
|
||||||
|
|
||||||
An OpenStack-Ansible environment can upgrade to a minor or a major version.
|
This guide provides information about the upgrade process from
|
||||||
|
|previous_release_formal_name| to |current_release_formal_name|
|
||||||
|
for OpenStack-Ansible.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
You can only upgrade between sequential releases.
|
You can only upgrade between sequential releases.
|
||||||
|
|
||||||
Upgrades between minor versions of OpenStack-Ansible require
|
|
||||||
updating the repository clone to the latest minor release tag, and then
|
Introduction
|
||||||
running playbooks against the target hosts. For more information, see
|
============
|
||||||
:ref:`upgrading-to-a-minor-version`.
|
|
||||||
|
|
||||||
For upgrades between major versions, the OpenStack-Ansible repository provides
|
For upgrades between major versions, the OpenStack-Ansible repository provides
|
||||||
playbooks and scripts to upgrade an environment. The ``run-upgrade.sh``
|
playbooks and scripts to upgrade an environment. The ``run-upgrade.sh``
|
||||||
@ -24,7 +25,11 @@ major upgrade process performs the following actions:
|
|||||||
- Places flag files that are created by the migration scripts in order to
|
- Places flag files that are created by the migration scripts in order to
|
||||||
achieve idempotency. These files are placed in the |upgrade_backup_dir|
|
achieve idempotency. These files are placed in the |upgrade_backup_dir|
|
||||||
directory.
|
directory.
|
||||||
- Upgrades the RabbitMQ server. See :ref:`setup-infra-playbook` for details.
|
- Upgrades the infrastructure servers.
|
||||||
|
See :ref:`setup-infra-playbook` for details.
|
||||||
|
|
||||||
For more information about the major upgrade process, see
|
For more information about the major upgrade process, see
|
||||||
:ref:`upgrading-by-using-a-script` and :ref:`upgrading-manually`.
|
:ref:`upgrading-by-using-a-script` and :ref:`upgrading-manually`.
|
||||||
|
|
||||||
|
.. include:: major-upgrades-with-script.rst
|
||||||
|
.. include:: major-upgrades-manual-upgrade.rst
|
@ -1,19 +1,19 @@
|
|||||||
.. _upgrading-to-a-minor-version:
|
=====================
|
||||||
|
Minor version upgrade
|
||||||
|
=====================
|
||||||
|
|
||||||
=================================
|
Upgrades between minor versions of OpenStack-Ansible require
|
||||||
Executing a minor version upgrade
|
updating the repository clone to the latest minor release tag, updating
|
||||||
=================================
|
the ansible roles, and then running playbooks against the target hosts.
|
||||||
|
This section provides instructions for those tasks.
|
||||||
Upgrades between minor versions of OpenStack-Ansible require updating the
|
|
||||||
repository to the latest minor release tag, and then running playbooks
|
|
||||||
against the target hosts. This section provides instructions for those tasks.
|
|
||||||
|
|
||||||
Prerequisites
|
Prerequisites
|
||||||
~~~~~~~~~~~~~
|
~~~~~~~~~~~~~
|
||||||
|
|
||||||
To avoid issues and simplify troubleshooting during the upgrade, disable the
|
To avoid issues and simplify troubleshooting during the upgrade, disable the
|
||||||
security hardening role by setting the ``apply_security_hardening`` variable
|
security hardening role by setting the ``apply_security_hardening`` variable
|
||||||
to ``False`` in the :file:`user_variables.yml` file.
|
to ``False`` in the :file:`user_variables.yml` file, and
|
||||||
|
backup your openstack-ansible installation.
|
||||||
|
|
||||||
Execute a minor version upgrade
|
Execute a minor version upgrade
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
@ -29,7 +29,7 @@ import sys
|
|||||||
|
|
||||||
# Create dynamic table file.
|
# Create dynamic table file.
|
||||||
CONF_PATH = os.path.dirname(os.path.realpath(__file__))
|
CONF_PATH = os.path.dirname(os.path.realpath(__file__))
|
||||||
SCENARIO_TABLE = 'contributor/scenario-table-gen.html'
|
SCENARIO_TABLE = 'user/aio/scenario-table-gen.html'
|
||||||
TABLE_FILE = os.path.join(CONF_PATH, SCENARIO_TABLE)
|
TABLE_FILE = os.path.join(CONF_PATH, SCENARIO_TABLE)
|
||||||
stg = imp.load_source(
|
stg = imp.load_source(
|
||||||
'scenario_table_gen',
|
'scenario_table_gen',
|
||||||
@ -338,7 +338,7 @@ upgrade_backup_dir = "``/etc/openstack_deploy."+previous_release_capital_name+"`
|
|||||||
|
|
||||||
# Used to reference the deploy guide
|
# Used to reference the deploy guide
|
||||||
deploy_guide_prefix = "http://docs.openstack.org/project-deploy-guide/openstack-ansible/{}/%s".format(deploy_branch_link_name)
|
deploy_guide_prefix = "http://docs.openstack.org/project-deploy-guide/openstack-ansible/{}/%s".format(deploy_branch_link_name)
|
||||||
dev_docs_prefix = "http://docs.openstack.org/openstack-ansible/{}%s".format(dev_branch_link_name)
|
dev_docs_prefix = "http://docs.openstack.org/openstack-ansible/{}/%s".format(deploy_branch_link_name)
|
||||||
|
|
||||||
rst_epilog = """
|
rst_epilog = """
|
||||||
.. |previous_release_branch_name| replace:: %s
|
.. |previous_release_branch_name| replace:: %s
|
||||||
|
@ -5,15 +5,25 @@ Developer Documentation
|
|||||||
In this section, you will find documentation relevant to developing
|
In this section, you will find documentation relevant to developing
|
||||||
OpenStack-Ansible.
|
OpenStack-Ansible.
|
||||||
|
|
||||||
For information on how to install and deploy OpenStack-Ansible, see the
|
For information on how to deploy your OpenStack-Ansible cloud, refer to the
|
||||||
`Deployment Guide <https://docs.openstack.org/project-deploy-guide/openstack-ansible/latest/>`_.
|
:deploy_guide:`Deployment Guide <index.html>` for step-by-step
|
||||||
|
instructions on how to deploy the OpenStack packages and
|
||||||
|
dependencies on your cloud using OpenStack-Ansible.
|
||||||
|
|
||||||
|
For user guides, see the :dev_docs:`User Guide <user/index.html>`.
|
||||||
|
|
||||||
|
For information on how to manage and operate OpenStack-Ansible, see the
|
||||||
|
see the :dev_docs:`Operations Guide <admin/index.html>`.
|
||||||
|
|
||||||
|
For in-depth technical information, see the
|
||||||
|
:dev_docs:`OpenStack-Ansible Reference <reference/index.html>`.
|
||||||
|
|
||||||
|
|
||||||
Contents:
|
Contents:
|
||||||
|
|
||||||
.. toctree::
|
.. toctree::
|
||||||
:maxdepth: 2
|
:maxdepth: 2
|
||||||
|
|
||||||
quickstart-aio
|
|
||||||
inventory-and-vars
|
inventory-and-vars
|
||||||
scripts
|
scripts
|
||||||
contribute
|
contribute
|
||||||
|
@ -51,13 +51,12 @@ arguments to ``ansible-playbook`` as a convenience.
|
|||||||
bootstrap-aio.sh
|
bootstrap-aio.sh
|
||||||
----------------
|
----------------
|
||||||
|
|
||||||
The ``bootstrap-aio.sh`` script prepares a host for an `All-In-One`_ (AIO)
|
The ``bootstrap-aio.sh`` script prepares a host for an
|
||||||
|
:ref:`All-In-One <quickstart-aio>` (AIO)
|
||||||
deployment for the purposes of development and gating. The script creates the
|
deployment for the purposes of development and gating. The script creates the
|
||||||
necessary partitions, directories, and configurations. The script can be
|
necessary partitions, directories, and configurations. The script can be
|
||||||
configured using environment variables - more details are provided on the
|
configured using environment variables - more details are provided on the
|
||||||
`All-In-One`_ page.
|
:ref:`All-In-One <quickstart-aio>` page.
|
||||||
|
|
||||||
.. _All-In-One: quickstart-aio.html
|
|
||||||
|
|
||||||
Development and Testing
|
Development and Testing
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
@ -1,8 +1,8 @@
|
|||||||
.. _network-appendix:
|
.. _container-networking:
|
||||||
|
|
||||||
================================
|
====================
|
||||||
Appendix G: Container networking
|
Container networking
|
||||||
================================
|
====================
|
||||||
|
|
||||||
OpenStack-Ansible deploys Linux containers (LXC) and uses Linux
|
OpenStack-Ansible deploys Linux containers (LXC) and uses Linux
|
||||||
bridging between the container and the host interfaces to ensure that
|
bridging between the container and the host interfaces to ensure that
|
||||||
@ -53,7 +53,7 @@ namespaces.
|
|||||||
The following image demonstrates how the container network interfaces are
|
The following image demonstrates how the container network interfaces are
|
||||||
connected to the host's bridges and physical network interfaces:
|
connected to the host's bridges and physical network interfaces:
|
||||||
|
|
||||||
.. image:: figures/networkcomponents.png
|
.. image:: ../figures/networkcomponents.png
|
||||||
|
|
||||||
Network diagrams
|
Network diagrams
|
||||||
~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~
|
||||||
@ -64,7 +64,7 @@ Hosts with services running in containers
|
|||||||
The following diagram shows how all of the interfaces and bridges interconnect
|
The following diagram shows how all of the interfaces and bridges interconnect
|
||||||
to provide network connectivity to the OpenStack deployment:
|
to provide network connectivity to the OpenStack deployment:
|
||||||
|
|
||||||
.. image:: figures/networkarch-container-external.png
|
.. image:: ../figures/networkarch-container-external.png
|
||||||
|
|
||||||
The interface ``lxcbr0`` provides connectivity for the containers to the
|
The interface ``lxcbr0`` provides connectivity for the containers to the
|
||||||
outside world, thanks to dnsmasq (dhcp/dns) + NAT.
|
outside world, thanks to dnsmasq (dhcp/dns) + NAT.
|
||||||
@ -84,7 +84,7 @@ OpenStack-Ansible deploys the Compute service on the physical host rather than
|
|||||||
in a container. The following diagram shows how to use bridges for
|
in a container. The following diagram shows how to use bridges for
|
||||||
network connectivity:
|
network connectivity:
|
||||||
|
|
||||||
.. image:: figures/networkarch-bare-external.png
|
.. image:: ../figures/networkarch-bare-external.png
|
||||||
|
|
||||||
Neutron traffic
|
Neutron traffic
|
||||||
---------------
|
---------------
|
||||||
@ -96,12 +96,12 @@ networking-agents container. The diagram shows how DHCP agents provide
|
|||||||
information (IP addresses and DNS servers) to the instances, and how routing
|
information (IP addresses and DNS servers) to the instances, and how routing
|
||||||
works on the image.
|
works on the image.
|
||||||
|
|
||||||
.. image:: figures/networking-neutronagents.png
|
.. image:: ../figures/networking-neutronagents.png
|
||||||
|
|
||||||
The following diagram shows how virtual machines connect to the ``br-vlan`` and
|
The following diagram shows how virtual machines connect to the ``br-vlan`` and
|
||||||
``br-vxlan`` bridges and send traffic to the network outside the host:
|
``br-vxlan`` bridges and send traffic to the network outside the host:
|
||||||
|
|
||||||
.. image:: figures/networking-compute.png
|
.. image:: ../figures/networking-compute.png
|
||||||
|
|
||||||
.. _openstack-user-config-reference:
|
.. _openstack-user-config-reference:
|
||||||
|
|
||||||
@ -112,7 +112,7 @@ The ``openstack_user_config.yml.example`` file is heavily commented with the
|
|||||||
details of how to do more advanced container networking configuration. The
|
details of how to do more advanced container networking configuration. The
|
||||||
contents of the file are shown here for reference.
|
contents of the file are shown here for reference.
|
||||||
|
|
||||||
.. literalinclude:: ../../etc/openstack_deploy/openstack_user_config.yml.example
|
.. literalinclude:: ../../../../etc/openstack_deploy/openstack_user_config.yml.example
|
||||||
:language: yaml
|
:language: yaml
|
||||||
:start-after: under the License.
|
:start-after: under the License.
|
||||||
|
|
15
doc/source/reference/architecture/index.rst
Normal file
@ -0,0 +1,15 @@
|
|||||||
|
============
|
||||||
|
Architecture
|
||||||
|
============
|
||||||
|
|
||||||
|
Many operational requirements have been taken into consideration for
|
||||||
|
the design of the OpenStack-Ansible project.
|
||||||
|
|
||||||
|
In this chapter, you can find details about `why` OpenStack-Ansible
|
||||||
|
was architected in this way.
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:maxdepth: 1
|
||||||
|
|
||||||
|
security.rst
|
||||||
|
container-networking.rst
|
@ -1,15 +1,13 @@
|
|||||||
====================
|
.. _security-design:
|
||||||
Appendix F: Security
|
|
||||||
====================
|
Security
|
||||||
|
========
|
||||||
|
|
||||||
Security is one of the top priorities within OpenStack-Ansible (OSA), and many
|
Security is one of the top priorities within OpenStack-Ansible (OSA), and many
|
||||||
security enhancements for OpenStack clouds are available in deployments by
|
security enhancements for OpenStack clouds are available in deployments by
|
||||||
default. This appendix provides a detailed overview of the most important
|
default. This section provides a detailed overview of the most important
|
||||||
security enhancements.
|
security enhancements.
|
||||||
|
|
||||||
For more information about configuring security, see
|
|
||||||
:deploy_guide:`Appendix H <app-advanced-config-options.html>`.
|
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
Every deployer has different security requirements.
|
Every deployer has different security requirements.
|
||||||
@ -33,7 +31,8 @@ certificates, keys, and CA certificates.
|
|||||||
|
|
||||||
To learn more about how to customize the deployment of encrypted
|
To learn more about how to customize the deployment of encrypted
|
||||||
communications, see
|
communications, see
|
||||||
:deploy_guide:`Securing services with SSL certificates <app-advanced-config-sslcertificates.html>`.
|
:deploy_guide:`Securing services with SSL
|
||||||
|
certificates <app-advanced-config-sslcertificates.html>`.
|
||||||
|
|
||||||
Host security hardening
|
Host security hardening
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
@ -55,27 +54,6 @@ to all deployments. The role has been carefully designed to perform as follows:
|
|||||||
* Balance security with OpenStack performance and functionality
|
* Balance security with OpenStack performance and functionality
|
||||||
* Run as quickly as possible
|
* Run as quickly as possible
|
||||||
|
|
||||||
The role is applicable to physical hosts within an OpenStack-Ansible deployment
|
|
||||||
that are operating as any type of node, infrastructure or compute. By
|
|
||||||
default, the role is enabled. You can disable it by changing the value of
|
|
||||||
the ``apply_security_hardening`` variable in the ``user_variables.yml`` file
|
|
||||||
to ``false``:
|
|
||||||
|
|
||||||
.. code-block:: yaml
|
|
||||||
|
|
||||||
apply_security_hardening: false
|
|
||||||
|
|
||||||
You can apply security hardening configurations to an existing environment or
|
|
||||||
audit an environment by using a playbook supplied with OpenStack-Ansible:
|
|
||||||
|
|
||||||
.. code-block:: bash
|
|
||||||
|
|
||||||
# Apply security hardening configurations
|
|
||||||
openstack-ansible security-hardening.yml
|
|
||||||
|
|
||||||
# Perform a quick audit by using Ansible's check mode
|
|
||||||
openstack-ansible --check security-hardening.yml
|
|
||||||
|
|
||||||
For more information about the security configurations, see the
|
For more information about the security configurations, see the
|
||||||
`security hardening role`_ documentation.
|
`security hardening role`_ documentation.
|
||||||
|
|
@ -1,5 +1,7 @@
|
|||||||
Using overrides
|
.. _user-overrides:
|
||||||
===============
|
|
||||||
|
Overriding default configuration
|
||||||
|
================================
|
||||||
|
|
||||||
user_*.yml files
|
user_*.yml files
|
||||||
~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~
|
||||||
@ -18,7 +20,7 @@ variables in files named following the ``user_*.yml`` pattern so they will be
|
|||||||
sourced alongside those used exclusively by OpenStack-Ansible.
|
sourced alongside those used exclusively by OpenStack-Ansible.
|
||||||
|
|
||||||
Ordering and precedence
|
Ordering and precedence
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~
|
^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
``user_*.yml`` files contain YAML variables which are applied as extra-vars
|
``user_*.yml`` files contain YAML variables which are applied as extra-vars
|
||||||
when executing ``openstack-ansible`` to run playbooks. They will be sourced
|
when executing ``openstack-ansible`` to run playbooks. They will be sourced
|
||||||
@ -26,8 +28,8 @@ in alphanumeric order by ``openstack-ansible``. If duplicate variables occur
|
|||||||
in the ``user_*.yml`` files, the variable in the last file read will take
|
in the ``user_*.yml`` files, the variable in the last file read will take
|
||||||
precedence.
|
precedence.
|
||||||
|
|
||||||
Adding extra python packages into the environment
|
Adding extra python packages
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
The system will allow you to install and build any package that is a python
|
The system will allow you to install and build any package that is a python
|
||||||
installable. The repository infrastructure will look for and create any
|
installable. The repository infrastructure will look for and create any
|
||||||
@ -64,8 +66,8 @@ Once the variables are set call the play ``repo-build.yml`` to build all of the
|
|||||||
wheels within the repository infrastructure. When ready run the target plays to
|
wheels within the repository infrastructure. When ready run the target plays to
|
||||||
deploy your overridden source code.
|
deploy your overridden source code.
|
||||||
|
|
||||||
Setting overrides in configuration files
|
Setting overrides in configuration files with config_template
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
All of the services that use YAML, JSON, or INI for configuration can receive
|
All of the services that use YAML, JSON, or INI for configuration can receive
|
||||||
overrides through the use of a Ansible action plugin named ``config_template``.
|
overrides through the use of a Ansible action plugin named ``config_template``.
|
||||||
@ -75,16 +77,14 @@ preset template option. All OpenStack-Ansible roles allow for this
|
|||||||
functionality where applicable. Files available to receive overrides can be
|
functionality where applicable. Files available to receive overrides can be
|
||||||
seen in the ``defaults/main.yml`` file as standard empty dictionaries (hashes).
|
seen in the ``defaults/main.yml`` file as standard empty dictionaries (hashes).
|
||||||
|
|
||||||
Practical guidance for using this feature is available in the
|
This module was not accepted into Ansible Core (see `PR1`_ and `PR2`_), and
|
||||||
:deploy_guide:`Deployment Guide <app-advanced-config-override.html>`.
|
will never be.
|
||||||
|
|
||||||
This module has been `rejected for inclusion`_ into Ansible Core.
|
|
||||||
|
|
||||||
.. _rejected for inclusion: https://github.com/ansible/ansible/pull/12555
|
|
||||||
|
|
||||||
|
.. _PR1: https://github.com/ansible/ansible/pull/12555
|
||||||
|
.. _PR2: https://github.com/ansible/ansible/pull/35453
|
||||||
|
|
||||||
config_template documentation
|
config_template documentation
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
These are the options available as found within the virtual module
|
These are the options available as found within the virtual module
|
||||||
documentation section.
|
documentation section.
|
||||||
@ -135,6 +135,13 @@ documentation section.
|
|||||||
Example task using the config_template module
|
Example task using the config_template module
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
In this task the ``test.ini.j2`` file is a template which will be rendered and
|
||||||
|
written to disk at ``/tmp/test.ini``. The **config_overrides** entry is a
|
||||||
|
dictionary (hash) which allows a deployer to set arbitrary data as overrides to
|
||||||
|
be written into the configuration file at run time. The **config_type** entry
|
||||||
|
specifies the type of configuration file the module will be interacting with;
|
||||||
|
available options are "yaml", "json", and "ini".
|
||||||
|
|
||||||
.. code-block:: yaml
|
.. code-block:: yaml
|
||||||
|
|
||||||
- name: Run config template ini
|
- name: Run config template ini
|
||||||
@ -145,8 +152,7 @@ Example task using the config_template module
|
|||||||
config_type: ini
|
config_type: ini
|
||||||
|
|
||||||
|
|
||||||
Example overrides dictionary (hash)
|
Here is an example override dictionary (hash)
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
.. code-block:: yaml
|
.. code-block:: yaml
|
||||||
|
|
||||||
@ -155,8 +161,7 @@ Example overrides dictionary (hash)
|
|||||||
new_item: 12345
|
new_item: 12345
|
||||||
|
|
||||||
|
|
||||||
Original template file ``test.ini.j2``
|
And here is the template file:
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
.. code-block:: ini
|
.. code-block:: ini
|
||||||
|
|
||||||
@ -164,9 +169,8 @@ Original template file ``test.ini.j2``
|
|||||||
value1 = abc
|
value1 = abc
|
||||||
value2 = 123
|
value2 = 123
|
||||||
|
|
||||||
|
The rendered file on disk, namely ``/tmp/test.ini`` looks like
|
||||||
Rendered on disk file ``/tmp/test.ini``
|
this:
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
.. code-block:: ini
|
.. code-block:: ini
|
||||||
|
|
||||||
@ -176,14 +180,6 @@ Rendered on disk file ``/tmp/test.ini``
|
|||||||
new_item = 12345
|
new_item = 12345
|
||||||
|
|
||||||
|
|
||||||
In this task the ``test.ini.j2`` file is a template which will be rendered and
|
|
||||||
written to disk at ``/tmp/test.ini``. The **config_overrides** entry is a
|
|
||||||
dictionary (hash) which allows a deployer to set arbitrary data as overrides to
|
|
||||||
be written into the configuration file at run time. The **config_type** entry
|
|
||||||
specifies the type of configuration file the module will be interacting with;
|
|
||||||
available options are "yaml", "json", and "ini".
|
|
||||||
|
|
||||||
|
|
||||||
Discovering available overrides
|
Discovering available overrides
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
@ -199,3 +195,260 @@ The list of overrides available may be found by executing:
|
|||||||
find . -name "main.yml" -exec grep '_.*_overrides:' {} \; \
|
find . -name "main.yml" -exec grep '_.*_overrides:' {} \; \
|
||||||
| grep -v "^#" \
|
| grep -v "^#" \
|
||||||
| sort -u
|
| sort -u
|
||||||
|
|
||||||
|
The following override variables are currently available:
|
||||||
|
|
||||||
|
Galera:
|
||||||
|
* galera_client_my_cnf_overrides
|
||||||
|
* galera_my_cnf_overrides
|
||||||
|
* galera_cluster_cnf_overrides
|
||||||
|
* galera_debian_cnf_overrides
|
||||||
|
|
||||||
|
Telemetry service (ceilometer):
|
||||||
|
* ceilometer_policy_overrides
|
||||||
|
* ceilometer_ceilometer_conf_overrides
|
||||||
|
* ceilometer_event_definitions_yaml_overrides
|
||||||
|
* ceilometer_event_pipeline_yaml_overrides
|
||||||
|
* ceilometer_pipeline_yaml_overrides
|
||||||
|
|
||||||
|
Block Storage (cinder):
|
||||||
|
* cinder_policy_overrides
|
||||||
|
* cinder_rootwrap_conf_overrides
|
||||||
|
* cinder_api_paste_ini_overrides
|
||||||
|
* cinder_cinder_conf_overrides
|
||||||
|
|
||||||
|
Image service (glance):
|
||||||
|
* glance_glance_api_paste_ini_overrides
|
||||||
|
* glance_glance_api_conf_overrides
|
||||||
|
* glance_glance_cache_conf_overrides
|
||||||
|
* glance_glance_manage_conf_overrides
|
||||||
|
* glance_glance_registry_paste_ini_overrides
|
||||||
|
* glance_glance_registry_conf_overrides
|
||||||
|
* glance_glance_scrubber_conf_overrides
|
||||||
|
* glance_glance_scheme_json_overrides
|
||||||
|
* glance_policy_overrides
|
||||||
|
|
||||||
|
Orchestration service (heat):
|
||||||
|
* heat_heat_conf_overrides
|
||||||
|
* heat_api_paste_ini_overrides
|
||||||
|
* heat_default_yaml_overrides
|
||||||
|
* heat_aws_rds_dbinstance_yaml_overrides
|
||||||
|
* heat_policy_overrides
|
||||||
|
|
||||||
|
Identity service (keystone):
|
||||||
|
* keystone_keystone_conf_overrides
|
||||||
|
* keystone_keystone_default_conf_overrides
|
||||||
|
* keystone_keystone_paste_ini_overrides
|
||||||
|
* keystone_policy_overrides
|
||||||
|
|
||||||
|
Networking service (neutron):
|
||||||
|
* neutron_neutron_conf_overrides
|
||||||
|
* neutron_ml2_conf_ini_overrides
|
||||||
|
* neutron_dhcp_agent_ini_overrides
|
||||||
|
* neutron_api_paste_ini_overrides
|
||||||
|
* neutron_rootwrap_conf_overrides
|
||||||
|
* neutron_policy_overrides
|
||||||
|
* neutron_dnsmasq_neutron_conf_overrides
|
||||||
|
* neutron_l3_agent_ini_overrides
|
||||||
|
* neutron_metadata_agent_ini_overrides
|
||||||
|
* neutron_metering_agent_ini_overrides
|
||||||
|
|
||||||
|
Compute service (nova):
|
||||||
|
* nova_nova_conf_overrides
|
||||||
|
* nova_rootwrap_conf_overrides
|
||||||
|
* nova_api_paste_ini_overrides
|
||||||
|
* nova_policy_overrides
|
||||||
|
|
||||||
|
Object Storage service (swift):
|
||||||
|
* swift_swift_conf_overrides
|
||||||
|
* swift_swift_dispersion_conf_overrides
|
||||||
|
* swift_proxy_server_conf_overrides
|
||||||
|
* swift_account_server_conf_overrides
|
||||||
|
* swift_account_server_replicator_conf_overrides
|
||||||
|
* swift_container_server_conf_overrides
|
||||||
|
* swift_container_server_replicator_conf_overrides
|
||||||
|
* swift_object_server_conf_overrides
|
||||||
|
* swift_object_server_replicator_conf_overrides
|
||||||
|
|
||||||
|
Tempest:
|
||||||
|
* tempest_tempest_conf_overrides
|
||||||
|
|
||||||
|
pip:
|
||||||
|
* pip_global_conf_overrides
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
Possible additional overrides can be found in the "Tunable Section"
|
||||||
|
of each role's ``main.yml`` file, such as
|
||||||
|
``/etc/ansible/roles/role_name/defaults/main.yml``.
|
||||||
|
|
||||||
|
Overriding OpenStack configuration defaults
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
OpenStack has many configuration options available in ``.conf`` files
|
||||||
|
(in a standard ``INI`` file format),
|
||||||
|
policy files (in a standard ``JSON`` format) and ``YAML`` files, and
|
||||||
|
can therefore use the ``config_template`` module described above.
|
||||||
|
|
||||||
|
OpenStack-Ansible enables you to reference any options in the
|
||||||
|
`OpenStack Configuration Reference`_ through the use of a simple set of
|
||||||
|
configuration entries in the ``/etc/openstack_deploy/user_variables.yml``.
|
||||||
|
|
||||||
|
.. _OpenStack Configuration Reference: http://docs.openstack.org/draft/config-reference/
|
||||||
|
|
||||||
|
Overriding .conf files
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
Most often, overrides are implemented for the ``<service>.conf`` files
|
||||||
|
(for example, ``nova.conf``). These files use a standard INI file format.
|
||||||
|
|
||||||
|
For example, you might want to add the following parameters to the
|
||||||
|
``nova.conf`` file:
|
||||||
|
|
||||||
|
.. code-block:: ini
|
||||||
|
|
||||||
|
[DEFAULT]
|
||||||
|
remove_unused_original_minimum_age_seconds = 43200
|
||||||
|
|
||||||
|
[libvirt]
|
||||||
|
cpu_mode = host-model
|
||||||
|
disk_cachemodes = file=directsync,block=none
|
||||||
|
|
||||||
|
[database]
|
||||||
|
idle_timeout = 300
|
||||||
|
max_pool_size = 10
|
||||||
|
|
||||||
|
To do this, you use the following configuration entry in the
|
||||||
|
``/etc/openstack_deploy/user_variables.yml`` file:
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
nova_nova_conf_overrides:
|
||||||
|
DEFAULT:
|
||||||
|
remove_unused_original_minimum_age_seconds: 43200
|
||||||
|
libvirt:
|
||||||
|
cpu_mode: host-model
|
||||||
|
disk_cachemodes: file=directsync,block=none
|
||||||
|
database:
|
||||||
|
idle_timeout: 300
|
||||||
|
max_pool_size: 10
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
The general format for the variable names used for overrides is
|
||||||
|
``<service>_<filename>_<file extension>_overrides``. For example, the variable
|
||||||
|
name used in these examples to add parameters to the ``nova.conf`` file is
|
||||||
|
``nova_nova_conf_overrides``.
|
||||||
|
|
||||||
|
You can also apply overrides on a per-host basis with the following
|
||||||
|
configuration in the ``/etc/openstack_deploy/openstack_user_config.yml``
|
||||||
|
file:
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
compute_hosts:
|
||||||
|
900089-compute001:
|
||||||
|
ip: 192.0.2.10
|
||||||
|
host_vars:
|
||||||
|
nova_nova_conf_overrides:
|
||||||
|
DEFAULT:
|
||||||
|
remove_unused_original_minimum_age_seconds: 43200
|
||||||
|
libvirt:
|
||||||
|
cpu_mode: host-model
|
||||||
|
disk_cachemodes: file=directsync,block=none
|
||||||
|
database:
|
||||||
|
idle_timeout: 300
|
||||||
|
max_pool_size: 10
|
||||||
|
|
||||||
|
Use this method for any files with the ``INI`` format for in OpenStack projects
|
||||||
|
deployed in OpenStack-Ansible.
|
||||||
|
|
||||||
|
Overriding .json files
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
To implement access controls that are different from the ones in a standard
|
||||||
|
OpenStack environment, you can adjust the default policies applied by services.
|
||||||
|
Policy files are in a ``JSON`` format.
|
||||||
|
|
||||||
|
For example, you might want to add the following policy in the ``policy.json``
|
||||||
|
file for the Identity service (keystone):
|
||||||
|
|
||||||
|
.. code-block:: json
|
||||||
|
|
||||||
|
{
|
||||||
|
"identity:foo": "rule:admin_required",
|
||||||
|
"identity:bar": "rule:admin_required"
|
||||||
|
}
|
||||||
|
|
||||||
|
To do this, you use the following configuration entry in the
|
||||||
|
``/etc/openstack_deploy/user_variables.yml`` file:
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
keystone_policy_overrides:
|
||||||
|
identity:foo: "rule:admin_required"
|
||||||
|
identity:bar: "rule:admin_required"
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
The general format for the variable names used for overrides is
|
||||||
|
``<service>_policy_overrides``. For example, the variable name used in this
|
||||||
|
example to add a policy to the Identity service (keystone) ``policy.json`` file
|
||||||
|
is ``keystone_policy_overrides``.
|
||||||
|
|
||||||
|
Use this method for any files with the ``JSON`` format in OpenStack projects
|
||||||
|
deployed in OpenStack-Ansible.
|
||||||
|
|
||||||
|
To assist you in finding the appropriate variable name to use for
|
||||||
|
overrides, the general format for the variable name is
|
||||||
|
``<service>_policy_overrides``.
|
||||||
|
|
||||||
|
Overriding .yml files
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
You can override ``.yml`` file values by supplying replacement YAML content.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
All default YAML file content is completely overwritten by the overrides,
|
||||||
|
so the entire YAML source (both the existing content and your changes)
|
||||||
|
must be provided.
|
||||||
|
|
||||||
|
For example, you might want to define a meter exclusion for all hardware
|
||||||
|
items in the default content of the ``pipeline.yml`` file for the
|
||||||
|
Telemetry service (ceilometer):
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
sources:
|
||||||
|
- name: meter_source
|
||||||
|
interval: 600
|
||||||
|
meters:
|
||||||
|
- "!hardware.*"
|
||||||
|
sinks:
|
||||||
|
- meter_sink
|
||||||
|
- name: foo_source
|
||||||
|
value: foo
|
||||||
|
|
||||||
|
To do this, you use the following configuration entry in the
|
||||||
|
``/etc/openstack_deploy/user_variables.yml`` file:
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
ceilometer_pipeline_yaml_overrides:
|
||||||
|
sources:
|
||||||
|
- name: meter_source
|
||||||
|
interval: 600
|
||||||
|
meters:
|
||||||
|
- "!hardware.*"
|
||||||
|
sinks:
|
||||||
|
- meter_sink
|
||||||
|
- name: source_foo
|
||||||
|
value: foo
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
The general format for the variable names used for overrides is
|
||||||
|
``<service>_<filename>_<file extension>_overrides``. For example, the variable
|
||||||
|
name used in this example to define a meter exclusion in the ``pipeline.yml`` file
|
||||||
|
for the Telemetry service (ceilometer) is ``ceilometer_pipeline_yaml_overrides``.
|
||||||
|
Before Width: | Height: | Size: 104 KiB After Width: | Height: | Size: 104 KiB |
Before Width: | Height: | Size: 107 KiB After Width: | Height: | Size: 107 KiB |
Before Width: | Height: | Size: 174 KiB After Width: | Height: | Size: 174 KiB |
Before Width: | Height: | Size: 180 KiB After Width: | Height: | Size: 180 KiB |
Before Width: | Height: | Size: 37 KiB After Width: | Height: | Size: 37 KiB |
Before Width: | Height: | Size: 114 KiB After Width: | Height: | Size: 114 KiB |
Before Width: | Height: | Size: 134 KiB After Width: | Height: | Size: 134 KiB |
@ -5,11 +5,26 @@ OpenStack-Ansible Reference
|
|||||||
This chapter contains all the extra reference information
|
This chapter contains all the extra reference information
|
||||||
to deploy, configure, or upgrade an OpenStack-Ansible cloud.
|
to deploy, configure, or upgrade an OpenStack-Ansible cloud.
|
||||||
|
|
||||||
|
For information on how to deploy your OpenStack-Ansible cloud, refer to the
|
||||||
|
:deploy_guide:`Deployment Guide <index.html>` for step-by-step
|
||||||
|
instructions on how to deploy the OpenStack packages and
|
||||||
|
dependencies on your cloud using OpenStack-Ansible.
|
||||||
|
|
||||||
|
For user guides, see the :dev_docs:`User Guide <user/index.html>`.
|
||||||
|
|
||||||
|
For information on how to manage and operate OpenStack-Ansible, see the
|
||||||
|
see the :dev_docs:`Operations Guide <admin/index.html>`.
|
||||||
|
|
||||||
|
For information on how to contribute, extend or develop OpenStack-Ansible,
|
||||||
|
see the :dev_docs:`Contributors Guide <contributor/index.html>`.
|
||||||
|
|
||||||
|
|
||||||
.. toctree::
|
.. toctree::
|
||||||
:maxdepth: 1
|
:maxdepth: 1
|
||||||
|
|
||||||
conventions.rst
|
conventions.rst
|
||||||
inventory/inventory.rst
|
inventory/inventory.rst
|
||||||
configuration/advanced-config.rst
|
configuration/advanced-config.rst
|
||||||
|
architecture/index.rst
|
||||||
commands/reference.rst
|
commands/reference.rst
|
||||||
upgrades/reference.rst
|
upgrades/reference.rst
|
||||||
|
@ -1,9 +1,8 @@
|
|||||||
|
.. _configuring-inventory:
|
||||||
|
|
||||||
Configuring the inventory
|
Configuring the inventory
|
||||||
=========================
|
=========================
|
||||||
|
|
||||||
conf.d
|
|
||||||
~~~~~~
|
|
||||||
|
|
||||||
Common OpenStack services and their configuration are defined by
|
Common OpenStack services and their configuration are defined by
|
||||||
OpenStack-Ansible in the
|
OpenStack-Ansible in the
|
||||||
``/etc/openstack_deploy/openstack_user_config.yml`` settings file.
|
``/etc/openstack_deploy/openstack_user_config.yml`` settings file.
|
||||||
@ -11,16 +10,24 @@ OpenStack-Ansible in the
|
|||||||
Additional services should be defined with a YAML file in
|
Additional services should be defined with a YAML file in
|
||||||
``/etc/openstack_deploy/conf.d``, in order to manage file size.
|
``/etc/openstack_deploy/conf.d``, in order to manage file size.
|
||||||
|
|
||||||
|
|
||||||
env.d
|
|
||||||
~~~~~
|
|
||||||
|
|
||||||
The ``/etc/openstack_deploy/env.d`` directory sources all YAML files into the
|
The ``/etc/openstack_deploy/env.d`` directory sources all YAML files into the
|
||||||
deployed environment, allowing a deployer to define additional group mappings.
|
deployed environment, allowing a deployer to define additional group mappings.
|
||||||
|
|
||||||
This directory is used to extend the environment skeleton, or modify the
|
This directory is used to extend the environment skeleton, or modify the
|
||||||
defaults defined in the ``inventory/env.d`` directory.
|
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 files
|
||||||
|
``/etc/openstack_deploy/openstack_inventory.json`` or
|
||||||
|
``/etc/openstack_deploy/openstack_hostnames_ips.yml``. This can
|
||||||
|
lead to file corruptions, and problems with the inventory: hosts
|
||||||
|
and container could disappear and new ones would appear,
|
||||||
|
breaking your existing deployment.
|
||||||
|
|
||||||
|
|
||||||
Configuration constraints
|
Configuration constraints
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
@ -44,6 +51,103 @@ 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
|
Using this name for a group in the configuration will result in a runtime
|
||||||
error.
|
error.
|
||||||
|
|
||||||
|
Customizing existing components
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
|
||||||
|
The ``cinder-volume`` component is deployed directly on the host by
|
||||||
|
default. See the ``env.d/cinder.yml`` file for this example.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
Deploy existing components on dedicated hosts
|
||||||
|
---------------------------------------------
|
||||||
|
|
||||||
|
To deploy a ``shared-infra`` component to dedicated hosts, modify the
|
||||||
|
files that specify the host groups and container groups for the component.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
|
||||||
Checking inventory configuration for errors
|
Checking inventory configuration for errors
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
@ -78,14 +78,17 @@ physical host and not in a container. For an example of ``is_metal: true``
|
|||||||
being used refer to ``inventory/env.d/cinder.yml`` in the
|
being used refer to ``inventory/env.d/cinder.yml`` in the
|
||||||
``container_skel`` section.
|
``container_skel`` section.
|
||||||
|
|
||||||
|
For more details, see :ref:`configuring-inventory`.
|
||||||
|
|
||||||
Outputs
|
Outputs
|
||||||
^^^^^^^
|
~~~~~~~
|
||||||
|
|
||||||
Once executed, the script will output an ``openstack_inventory.json`` file into
|
Once executed, the script will output an ``openstack_inventory.json`` file into
|
||||||
the directory specified with the ``--config`` argument. This is used as the
|
the directory specified with the ``--config`` argument. This is used as the
|
||||||
source of truth for repeated runs.
|
source of truth for repeated runs.
|
||||||
|
|
||||||
.. note::
|
.. warning::
|
||||||
|
|
||||||
The ``openstack_inventory.json`` file is the source of truth for the
|
The ``openstack_inventory.json`` file is the source of truth for the
|
||||||
environment. Deleting this in a production environment means that the UUID
|
environment. Deleting this in a production environment means that the UUID
|
||||||
portion of container names will be regenerated, which then results in new
|
portion of container names will be regenerated, which then results in new
|
||||||
|
@ -14,5 +14,6 @@ for OpenStack-Ansible.
|
|||||||
|
|
||||||
generate-inventory
|
generate-inventory
|
||||||
configure-inventory
|
configure-inventory
|
||||||
|
understanding-inventory
|
||||||
manage-inventory
|
manage-inventory
|
||||||
advanced-topics
|
advanced-topics
|
||||||
|
@ -1,6 +1,7 @@
|
|||||||
================================================
|
.. _inventory-in-depth:
|
||||||
Appendix E: Customizing host and service layouts
|
|
||||||
================================================
|
Understanding the inventory
|
||||||
|
===========================
|
||||||
|
|
||||||
The default layout of containers and services in OpenStack-Ansible (OSA) is
|
The default layout of containers and services in OpenStack-Ansible (OSA) is
|
||||||
determined by the ``/etc/openstack_deploy/openstack_user_config.yml`` file and
|
determined by the ``/etc/openstack_deploy/openstack_user_config.yml`` file and
|
||||||
@ -21,8 +22,8 @@ To customize the layout of the components for your deployment, modify the
|
|||||||
host groups and container groups appropriately before running the installation
|
host groups and container groups appropriately before running the installation
|
||||||
playbooks.
|
playbooks.
|
||||||
|
|
||||||
Understanding host groups
|
Understanding host groups (conf.d structure)
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
As part of the initial configuration, each target host appears either in the
|
As part of the initial configuration, each target host appears either in the
|
||||||
``/etc/openstack_deploy/openstack_user_config.yml`` file or in files within
|
``/etc/openstack_deploy/openstack_user_config.yml`` file or in files within
|
||||||
@ -50,8 +51,8 @@ variables to any component containers on the specific host.
|
|||||||
particularly for new services, by using a new file in the
|
particularly for new services, by using a new file in the
|
||||||
``conf.d/`` directory.
|
``conf.d/`` directory.
|
||||||
|
|
||||||
Understanding container groups
|
Understanding container groups (env.d structure)
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
Additional group mappings are located within files in the
|
Additional group mappings are located within files in the
|
||||||
``/etc/openstack_deploy/env.d/`` directory. These groups are treated as
|
``/etc/openstack_deploy/env.d/`` directory. These groups are treated as
|
||||||
@ -61,11 +62,11 @@ groups, that define where each service deploys. By reviewing files within the
|
|||||||
in the default layout.
|
in the default layout.
|
||||||
|
|
||||||
For example, the ``shared-infra.yml`` file defines a container group,
|
For example, the ``shared-infra.yml`` file defines a container group,
|
||||||
``shared- infra_containers``, as a subset of the all_containers inventory
|
``shared-infra_containers``, as a subset of the ``all_containers``
|
||||||
group. The ``shared- infra_containers`` container group is mapped to the
|
inventory group. The ``shared- infra_containers`` container group is
|
||||||
``shared-infra_hosts`` host group. All of the service components in the
|
mapped to the ``shared-infra_hosts`` host group. All of the service
|
||||||
``shared-infra_containers`` container group are deployed to each target host
|
components in the ``shared-infra_containers`` container group are
|
||||||
in the ``shared-infra_hosts host`` group.
|
deployed to each target host in the ``shared-infra_hosts host`` group.
|
||||||
|
|
||||||
Within a ``physical_skel`` section, the OpenStack-Ansible dynamic inventory
|
Within a ``physical_skel`` section, the OpenStack-Ansible dynamic inventory
|
||||||
expects to find a pair of keys. The first key maps to items in the
|
expects to find a pair of keys. The first key maps to items in the
|
||||||
@ -93,98 +94,53 @@ group. Other services might have more complex deployment needs. They define and
|
|||||||
consume inventory container groups differently. Mapping components to several
|
consume inventory container groups differently. Mapping components to several
|
||||||
groups in this way allows flexible targeting of roles and tasks.
|
groups in this way allows flexible targeting of roles and tasks.
|
||||||
|
|
||||||
Customizing existing components
|
.. _affinity:
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
Deploying directly on hosts
|
Affinity
|
||||||
---------------------------
|
~~~~~~~~
|
||||||
|
|
||||||
To deploy a component directly on the host instead of within a container, set
|
When OpenStack-Ansible generates its dynamic inventory, the affinity
|
||||||
the ``is_metal`` property to ``true`` for the container group in the
|
setting determines how many containers of a similar type are deployed on a
|
||||||
``container_skel`` section in the appropriate file.
|
single physical host.
|
||||||
|
|
||||||
The use of ``container_vars`` and mapping from container groups to host groups
|
Using ``shared-infra_hosts`` as an example, consider this
|
||||||
is the same for a service deployed directly onto the host.
|
``openstack_user_config.yml`` configuration:
|
||||||
|
|
||||||
.. note::
|
|
||||||
|
|
||||||
The ``cinder-volume`` component is deployed directly on the host by
|
|
||||||
default. See the ``env.d/cinder.yml`` file for this example.
|
|
||||||
|
|
||||||
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 :deploy_guide:`affinity <app-advanced-config-affinity.html>`
|
|
||||||
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.
|
|
||||||
|
|
||||||
Deploy existing components on dedicated hosts
|
|
||||||
---------------------------------------------
|
|
||||||
|
|
||||||
To deploy a ``shared-infra`` component to dedicated hosts, modify the
|
|
||||||
files that specify the host groups and container groups for the component.
|
|
||||||
|
|
||||||
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
|
.. code-block:: yaml
|
||||||
|
|
||||||
container_skel:
|
shared-infra_hosts:
|
||||||
galera_container:
|
infra1:
|
||||||
belongs_to:
|
ip: 172.29.236.101
|
||||||
- db_containers
|
infra2:
|
||||||
contains:
|
ip: 172.29.236.102
|
||||||
- galera
|
infra3:
|
||||||
properties:
|
ip: 172.29.236.103
|
||||||
is_metal: true
|
|
||||||
|
|
||||||
.. note::
|
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.
|
||||||
|
|
||||||
To deploy within containers on these dedicated hosts, omit the
|
If you are deploying a stand-alone Object Storage (swift) environment,
|
||||||
``is_metal: true`` property.
|
you can skip the deployment of RabbitMQ. If you use this configuration,
|
||||||
|
your ``openstack_user_config.yml`` file would look as follows:
|
||||||
#. 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
|
.. code-block:: yaml
|
||||||
|
|
||||||
physical_skel:
|
shared-infra_hosts:
|
||||||
db_containers:
|
infra1:
|
||||||
belongs_to:
|
affinity:
|
||||||
- all_containers
|
rabbit_mq_container: 0
|
||||||
db_hosts:
|
ip: 172.29.236.101
|
||||||
belongs_to:
|
infra2:
|
||||||
- hosts
|
affinity:
|
||||||
|
rabbit_mq_container: 0
|
||||||
|
ip: 172.29.236.102
|
||||||
|
infra3:
|
||||||
|
affinity:
|
||||||
|
rabbit_mq_container: 0
|
||||||
|
ip: 172.29.236.103
|
||||||
|
|
||||||
#. Define the host group (``db_hosts``) in a ``conf.d/`` file (such as
|
This configuration deploys a Memcached container and a database container
|
||||||
``galera.yml``). For example:
|
on each host, but no RabbitMQ containers.
|
||||||
|
|
||||||
.. 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.
|
|
@ -1,6 +1,8 @@
|
|||||||
===========
|
.. _quickstart-aio:
|
||||||
Quick Start
|
|
||||||
===========
|
===============
|
||||||
|
Quickstart: AIO
|
||||||
|
===============
|
||||||
|
|
||||||
All-in-one (AIO) builds are a great way to perform an OpenStack-Ansible build
|
All-in-one (AIO) builds are a great way to perform an OpenStack-Ansible build
|
||||||
for:
|
for:
|
||||||
@ -158,7 +160,7 @@ Notes:
|
|||||||
|
|
||||||
The next step is to bootstrap Ansible and the Ansible roles for the
|
The next step is to bootstrap Ansible and the Ansible roles for the
|
||||||
development environment. Deployers can customize roles by adding variables to
|
development environment. Deployers can customize roles by adding variables to
|
||||||
override the defaults in each role (see :ref:`adding-galaxy-roles`). Run the
|
override the defaults in each role (see :ref:`user-overrides`). Run the
|
||||||
following to bootstrap Ansible:
|
following to bootstrap Ansible:
|
||||||
|
|
||||||
.. code-block:: shell-session
|
.. code-block:: shell-session
|
||||||
@ -234,6 +236,7 @@ Keystone service, execute:
|
|||||||
|
|
||||||
Rebooting an AIO
|
Rebooting an AIO
|
||||||
----------------
|
----------------
|
||||||
|
|
||||||
As the AIO includes all three cluster members of MariaDB/Galera, the cluster
|
As the AIO includes all three cluster members of MariaDB/Galera, the cluster
|
||||||
has to be re-initialized after the host is rebooted.
|
has to be re-initialized after the host is rebooted.
|
||||||
|
|
||||||
@ -251,6 +254,7 @@ section in the operations guide.
|
|||||||
|
|
||||||
Rebuilding an AIO
|
Rebuilding an AIO
|
||||||
-----------------
|
-----------------
|
||||||
|
|
||||||
Sometimes it may be useful to destroy all the containers and rebuild the AIO.
|
Sometimes it may be useful to destroy all the containers and rebuild the AIO.
|
||||||
While it is preferred that the AIO is entirely destroyed and rebuilt, this
|
While it is preferred that the AIO is entirely destroyed and rebuilt, this
|
||||||
isn't always practical. As such the following may be executed instead:
|
isn't always practical. As such the following may be executed instead:
|
1
doc/source/user/aio/scenario-table-gen.html
Normal file
@ -0,0 +1 @@
|
|||||||
|
<table border="1"><thead valign="bottom"><tr><th style="padding-left:5px;padding-right:5px;" class="head"></th><th style="padding-left:5px;padding-right:5px;" class="head">aio_basekit</th><th style="padding-left:5px;padding-right:5px;" class="head">aio_lxc</th><th style="padding-left:5px;padding-right:5px;" class="head">aio_metal</th><th style="padding-left:5px;padding-right:5px;" class="head">ceph</th><th style="padding-left:5px;padding-right:5px;" class="head">octavia</th><th style="padding-left:5px;padding-right:5px;" class="head">tacker</th><th style="padding-left:5px;padding-right:5px;" class="head">translations</th></tr></thead><tbody valign="top"><tr><td align="left">heat</td><td> </td><td align="center">X</td><td align="center">X</td><td> </td><td> </td><td align="center">X</td><td align="center">X</td></tr><tr><td align="left">tacker</td><td> </td><td> </td><td> </td><td> </td><td> </td><td align="center">X</td><td> </td></tr><tr><td align="left">octavia</td><td> </td><td> </td><td> </td><td> </td><td align="center">X</td><td> </td><td align="center">X</td></tr><tr><td align="left">glance</td><td align="center">X</td><td align="center">X</td><td align="center">X</td><td align="center">X</td><td align="center">X</td><td> </td><td align="center">X</td></tr><tr><td align="left">neutron</td><td align="center">X</td><td align="center">X</td><td align="center">X</td><td align="center">X</td><td align="center">X</td><td> </td><td align="center">X</td></tr><tr><td align="left">trove</td><td> </td><td> </td><td> </td><td> </td><td> </td><td> </td><td align="center">X</td></tr><tr><td align="left">magnum</td><td> </td><td> </td><td> </td><td> </td><td> </td><td> </td><td align="center">X</td></tr><tr><td align="left">keystone</td><td align="center">X</td><td align="center">X</td><td align="center">X</td><td align="center">X</td><td align="center">X</td><td align="center">X</td><td align="center">X</td></tr><tr><td align="left">designate</td><td> </td><td align="center">X</td><td> </td><td> </td><td> </td><td> </td><td align="center">X</td></tr><tr><td align="left">ceph</td><td> </td><td> </td><td> </td><td align="center">X</td><td> </td><td> </td><td> </td></tr><tr><td align="left">nova</td><td align="center">X</td><td align="center">X</td><td align="center">X</td><td align="center">X</td><td align="center">X</td><td> </td><td align="center">X</td></tr><tr><td align="left">swift</td><td> </td><td align="center">X</td><td align="center">X</td><td> </td><td> </td><td> </td><td align="center">X</td></tr><tr><td align="left">haproxy</td><td align="center">X</td><td align="center">X</td><td> </td><td align="center">X</td><td align="center">X</td><td align="center">X</td><td align="center">X</td></tr><tr><td align="left">cinder</td><td align="center">X</td><td align="center">X</td><td align="center">X</td><td align="center">X</td><td> </td><td> </td><td align="center">X</td></tr><tr><td align="left">horizon</td><td> </td><td align="center">X</td><td> </td><td> </td><td> </td><td> </td><td align="center">X</td></tr><tr><td align="left">sahara</td><td> </td><td> </td><td> </td><td> </td><td> </td><td> </td><td align="center">X</td></tr></tbody></table>
|
@ -1,13 +1,10 @@
|
|||||||
.. _production-ceph-environment-config:
|
.. _production-ceph-environment-config:
|
||||||
|
|
||||||
=============================================================
|
=======================
|
||||||
Appendix D: Example Ceph production environment configuration
|
Ceph production example
|
||||||
=============================================================
|
=======================
|
||||||
|
|
||||||
Introduction
|
This section describes an example production environment for a working
|
||||||
~~~~~~~~~~~~
|
|
||||||
|
|
||||||
This appendix describes an example production environment for a working
|
|
||||||
OpenStack-Ansible (OSA) deployment with high availability services and using
|
OpenStack-Ansible (OSA) deployment with high availability services and using
|
||||||
the Ceph backend for images, volumes, and instances.
|
the Ceph backend for images, volumes, and instances.
|
||||||
|
|
||||||
@ -25,9 +22,30 @@ This example environment has the following characteristics:
|
|||||||
* Internet access via the router address 172.29.236.1 on the
|
* Internet access via the router address 172.29.236.1 on the
|
||||||
Management Network
|
Management Network
|
||||||
|
|
||||||
.. image:: figures/arch-layout-production-ceph.png
|
.. image:: ../figures/arch-layout-production-ceph.png
|
||||||
:width: 100%
|
:width: 100%
|
||||||
|
|
||||||
|
Integration with Ceph
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
OpenStack-Ansible allows `Ceph storage <https://ceph.com>`_ cluster
|
||||||
|
integration in two ways:
|
||||||
|
|
||||||
|
* connecting to your own ceph cluster by pointing to its information
|
||||||
|
in ``user_variables.yml``
|
||||||
|
* deploying a ceph cluster by using the roles maintained by the
|
||||||
|
`Ceph-Ansible`_ project. Deployers can enable the ``ceph-install``
|
||||||
|
playbook by adding hosts to the ``ceph-mon_hosts`` and ``ceph-osd_hosts``
|
||||||
|
groups in ``openstack_user_config.yml``, and then configuring
|
||||||
|
`Ceph-Ansible specific vars
|
||||||
|
<https://github.com/ceph/ceph-ansible/blob/master/group_vars/all.yml.sample>`_
|
||||||
|
in the OpenStack-Ansible ``user_variables.yml`` file.
|
||||||
|
|
||||||
|
.. _Ceph-Ansible: https://github.com/ceph/ceph-ansible/
|
||||||
|
|
||||||
|
This example will focus on the deployment of both OpenStack-Ansible
|
||||||
|
and its Ceph cluster.
|
||||||
|
|
||||||
Network configuration
|
Network configuration
|
||||||
~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
@ -89,7 +107,7 @@ following is the ``/etc/network/interfaces`` file for ``infra1``.
|
|||||||
configuration files are replaced with the appropriate name. The same
|
configuration files are replaced with the appropriate name. The same
|
||||||
applies to additional network interfaces.
|
applies to additional network interfaces.
|
||||||
|
|
||||||
.. literalinclude:: ../../etc/network/interfaces.d/openstack_interface.cfg.prod.example
|
.. literalinclude:: ../../../../etc/network/interfaces.d/openstack_interface.cfg.prod.example
|
||||||
|
|
||||||
Deployment configuration
|
Deployment configuration
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
@ -102,7 +120,7 @@ environment layout.
|
|||||||
|
|
||||||
The following configuration describes the layout for this environment.
|
The following configuration describes the layout for this environment.
|
||||||
|
|
||||||
.. literalinclude:: ../../etc/openstack_deploy/openstack_user_config.yml.prod-ceph.example
|
.. literalinclude:: ../../../../etc/openstack_deploy/openstack_user_config.yml.prod-ceph.example
|
||||||
|
|
||||||
Environment customizations
|
Environment customizations
|
||||||
--------------------------
|
--------------------------
|
||||||
@ -113,10 +131,11 @@ the services will run in a container (the default), or on the host (on
|
|||||||
metal).
|
metal).
|
||||||
|
|
||||||
For a ceph environment, you can run the ``cinder-volume`` in a container.
|
For a ceph environment, you can run the ``cinder-volume`` in a container.
|
||||||
To do this you will need to create a ``/etc/openstack_deploy/env.d/cinder.yml`` file
|
To do this you will need to create a
|
||||||
with the following content:
|
``/etc/openstack_deploy/env.d/cinder.yml`` file with the following
|
||||||
|
content:
|
||||||
|
|
||||||
.. literalinclude:: ../../etc/openstack_deploy/env.d/cinder-volume.yml.container.example
|
.. literalinclude:: ../../../../etc/openstack_deploy/env.d/cinder-volume.yml.container.example
|
||||||
|
|
||||||
User variables
|
User variables
|
||||||
--------------
|
--------------
|
||||||
@ -127,7 +146,7 @@ overrides for the default variables.
|
|||||||
For this example environment, we configure a HA load balancer.
|
For this example environment, we configure a HA load balancer.
|
||||||
We implement the load balancer (HAProxy) with an HA layer (keepalived)
|
We implement the load balancer (HAProxy) with an HA layer (keepalived)
|
||||||
on the infrastructure hosts.
|
on the infrastructure hosts.
|
||||||
Your ``/etc/openstack_deploy/user_variables.yml`` must have the following content
|
Your ``/etc/openstack_deploy/user_variables.yml`` must have the
|
||||||
to configure haproxy, keepalived and ceph:
|
following content to configure haproxy, keepalived and ceph:
|
||||||
|
|
||||||
.. literalinclude:: ../../etc/openstack_deploy/user_variables.yml.prod-ceph.example
|
.. literalinclude:: ../../../../etc/openstack_deploy/user_variables.yml.prod-ceph.example
|
Before Width: | Height: | Size: 163 KiB After Width: | Height: | Size: 163 KiB |
Before Width: | Height: | Size: 34 KiB After Width: | Height: | Size: 34 KiB |
Before Width: | Height: | Size: 213 KiB After Width: | Height: | Size: 213 KiB |
Before Width: | Height: | Size: 41 KiB After Width: | Height: | Size: 41 KiB |
Before Width: | Height: | Size: 215 KiB After Width: | Height: | Size: 215 KiB |
Before Width: | Height: | Size: 38 KiB After Width: | Height: | Size: 38 KiB |
@ -1,16 +1,31 @@
|
|||||||
=============
|
==========
|
||||||
Upgrade Guide
|
User Guide
|
||||||
=============
|
==========
|
||||||
|
|
||||||
This guide provides information about the upgrade process from
|
In this section, you will find user stories and examples relevant to
|
||||||
|previous_release_formal_name| to |current_release_formal_name|
|
deploying OpenStack-Ansible.
|
||||||
for OpenStack-Ansible.
|
|
||||||
|
For information on how to deploy your OpenStack-Ansible cloud, refer to the
|
||||||
|
:deploy_guide:`Deployment Guide <index.html>` for step-by-step
|
||||||
|
instructions on how to deploy the OpenStack packages and
|
||||||
|
dependencies on your cloud using OpenStack-Ansible.
|
||||||
|
|
||||||
|
For information on how to manage and operate OpenStack-Ansible, see the
|
||||||
|
see the :dev_docs:`Operations Guide <admin/index.html>`.
|
||||||
|
|
||||||
|
For information on how to contribute, extend or develop OpenStack-Ansible,
|
||||||
|
see the :dev_docs:`Contributors Guide <contributor/index.html>`.
|
||||||
|
|
||||||
|
For in-depth technical information, see the
|
||||||
|
:dev_docs:`OpenStack-Ansible Reference <reference/index.html>`.
|
||||||
|
|
||||||
.. toctree::
|
.. toctree::
|
||||||
:maxdepth: 2
|
:maxdepth: 1
|
||||||
|
|
||||||
overview
|
aio/quickstart.rst
|
||||||
minor-upgrade
|
test/example.rst
|
||||||
script-upgrade
|
prod/example.rst
|
||||||
manual-upgrade
|
limited-connectivity/index.rst
|
||||||
reference
|
l3pods/example.rst
|
||||||
|
ceph/full-deploy.rst
|
||||||
|
security/index.rst
|
||||||
|
@ -1,13 +1,10 @@
|
|||||||
.. _pod-environment-config:
|
.. _pod-environment-config:
|
||||||
|
|
||||||
============================================================
|
==========================
|
||||||
Appendix C: Example layer 3 routed environment configuration
|
Routed environment example
|
||||||
============================================================
|
==========================
|
||||||
|
|
||||||
Introduction
|
This section describes an example production environment for a working
|
||||||
~~~~~~~~~~~~
|
|
||||||
|
|
||||||
This appendix describes an example production environment for a working
|
|
||||||
OpenStack-Ansible (OSA) deployment with high availability services where
|
OpenStack-Ansible (OSA) deployment with high availability services where
|
||||||
provider networks and connectivity between physical machines are routed
|
provider networks and connectivity between physical machines are routed
|
||||||
(layer 3).
|
(layer 3).
|
||||||
@ -27,7 +24,7 @@ This example environment has the following characteristics:
|
|||||||
Tunnel, and Storage Networks of each pod. The gateway address is the first
|
Tunnel, and Storage Networks of each pod. The gateway address is the first
|
||||||
usable address within each network's subnet.
|
usable address within each network's subnet.
|
||||||
|
|
||||||
.. image:: figures/arch-layout-production.png
|
.. image:: ../figures/arch-layout-production.png
|
||||||
:width: 100%
|
:width: 100%
|
||||||
|
|
||||||
Network configuration
|
Network configuration
|
||||||
@ -105,7 +102,7 @@ following is the ``/etc/network/interfaces`` file for ``infra1``.
|
|||||||
configuration files are replaced with the appropriate name. The same
|
configuration files are replaced with the appropriate name. The same
|
||||||
applies to additional network interfaces.
|
applies to additional network interfaces.
|
||||||
|
|
||||||
.. literalinclude:: ../../etc/network/interfaces.d/openstack_interface.cfg.pod.example
|
.. literalinclude:: ../../../../etc/network/interfaces.d/openstack_interface.cfg.pod.example
|
||||||
|
|
||||||
Deployment configuration
|
Deployment configuration
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
@ -130,7 +127,7 @@ pods.
|
|||||||
|
|
||||||
The following configuration describes the layout for this environment.
|
The following configuration describes the layout for this environment.
|
||||||
|
|
||||||
.. literalinclude:: ../../etc/openstack_deploy/openstack_user_config.yml.pod.example
|
.. literalinclude:: ../../../../etc/openstack_deploy/openstack_user_config.yml.pod.example
|
||||||
|
|
||||||
Environment customizations
|
Environment customizations
|
||||||
--------------------------
|
--------------------------
|
||||||
@ -144,7 +141,7 @@ For this environment, the ``cinder-volume`` runs in a container on the
|
|||||||
infrastructure hosts. To achieve this, implement
|
infrastructure hosts. To achieve this, implement
|
||||||
``/etc/openstack_deploy/env.d/cinder.yml`` with the following content:
|
``/etc/openstack_deploy/env.d/cinder.yml`` with the following content:
|
||||||
|
|
||||||
.. literalinclude:: ../../etc/openstack_deploy/env.d/cinder-volume.yml.container.example
|
.. literalinclude:: ../../../../etc/openstack_deploy/env.d/cinder-volume.yml.container.example
|
||||||
|
|
||||||
User variables
|
User variables
|
||||||
--------------
|
--------------
|
||||||
@ -156,4 +153,4 @@ For this environment, implement the load balancer on the infrastructure
|
|||||||
hosts. Ensure that keepalived is also configured with HAProxy in
|
hosts. Ensure that keepalived is also configured with HAProxy in
|
||||||
``/etc/openstack_deploy/user_variables.yml`` with the following content.
|
``/etc/openstack_deploy/user_variables.yml`` with the following content.
|
||||||
|
|
||||||
.. literalinclude:: ../../etc/openstack_deploy/user_variables.yml.prod.example
|
.. literalinclude:: ../../../../etc/openstack_deploy/user_variables.yml.prod.example
|
@ -1,8 +1,6 @@
|
|||||||
.. _limited-connectivity-appendix:
|
====================================
|
||||||
|
Installing with limited connectivity
|
||||||
================================================
|
====================================
|
||||||
Appendix H: Installing with limited connectivity
|
|
||||||
================================================
|
|
||||||
|
|
||||||
Many playbooks and roles in OpenStack-Ansible retrieve dependencies from the
|
Many playbooks and roles in OpenStack-Ansible retrieve dependencies from the
|
||||||
public Internet by default. Many deployers block direct outbound connectivity
|
public Internet by default. Many deployers block direct outbound connectivity
|
@ -1,13 +1,10 @@
|
|||||||
.. _production-environment-config:
|
.. _production-environment-config:
|
||||||
|
|
||||||
========================================================
|
======================
|
||||||
Appendix B: Example production environment configuration
|
Production environment
|
||||||
========================================================
|
======================
|
||||||
|
|
||||||
Introduction
|
This is an example production environment for a working
|
||||||
~~~~~~~~~~~~
|
|
||||||
|
|
||||||
This appendix describes an example production environment for a working
|
|
||||||
OpenStack-Ansible (OSA) deployment with high availability services.
|
OpenStack-Ansible (OSA) deployment with high availability services.
|
||||||
|
|
||||||
This example environment has the following characteristics:
|
This example environment has the following characteristics:
|
||||||
@ -24,8 +21,9 @@ This example environment has the following characteristics:
|
|||||||
* Internet access via the router address 172.29.236.1 on the
|
* Internet access via the router address 172.29.236.1 on the
|
||||||
Management Network
|
Management Network
|
||||||
|
|
||||||
.. image:: figures/arch-layout-production.png
|
.. image:: ../figures/arch-layout-production.png
|
||||||
:width: 100%
|
:width: 100%
|
||||||
|
:alt: Production environment host layout
|
||||||
|
|
||||||
Network configuration
|
Network configuration
|
||||||
~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~
|
||||||
@ -84,7 +82,7 @@ following is the ``/etc/network/interfaces`` file for ``infra1``.
|
|||||||
configuration files are replaced with the appropriate name. The same
|
configuration files are replaced with the appropriate name. The same
|
||||||
applies to additional network interfaces.
|
applies to additional network interfaces.
|
||||||
|
|
||||||
.. literalinclude:: ../../etc/network/interfaces.d/openstack_interface.cfg.prod.example
|
.. literalinclude:: ../../../../etc/network/interfaces.d/openstack_interface.cfg.prod.example
|
||||||
|
|
||||||
Deployment configuration
|
Deployment configuration
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
@ -97,7 +95,7 @@ environment layout.
|
|||||||
|
|
||||||
The following configuration describes the layout for this environment.
|
The following configuration describes the layout for this environment.
|
||||||
|
|
||||||
.. literalinclude:: ../../etc/openstack_deploy/openstack_user_config.yml.prod.example
|
.. literalinclude:: ../../../../etc/openstack_deploy/openstack_user_config.yml.prod.example
|
||||||
|
|
||||||
Environment customizations
|
Environment customizations
|
||||||
--------------------------
|
--------------------------
|
||||||
@ -111,7 +109,7 @@ For this environment, the ``cinder-volume`` runs in a container on the
|
|||||||
infrastructure hosts. To achieve this, implement
|
infrastructure hosts. To achieve this, implement
|
||||||
``/etc/openstack_deploy/env.d/cinder.yml`` with the following content:
|
``/etc/openstack_deploy/env.d/cinder.yml`` with the following content:
|
||||||
|
|
||||||
.. literalinclude:: ../../etc/openstack_deploy/env.d/cinder-volume.yml.container.example
|
.. literalinclude:: ../../../../etc/openstack_deploy/env.d/cinder-volume.yml.container.example
|
||||||
|
|
||||||
User variables
|
User variables
|
||||||
--------------
|
--------------
|
||||||
@ -123,4 +121,4 @@ For this environment, implement the load balancer on the infrastructure
|
|||||||
hosts. Ensure that keepalived is also configured with HAProxy in
|
hosts. Ensure that keepalived is also configured with HAProxy in
|
||||||
``/etc/openstack_deploy/user_variables.yml`` with the following content.
|
``/etc/openstack_deploy/user_variables.yml`` with the following content.
|
||||||
|
|
||||||
.. literalinclude:: ../../etc/openstack_deploy/user_variables.yml.prod.example
|
.. literalinclude:: ../../../../etc/openstack_deploy/user_variables.yml.prod.example
|
29
doc/source/user/security/hardening.rst
Normal file
@ -0,0 +1,29 @@
|
|||||||
|
Apply ansible-hardening
|
||||||
|
=======================
|
||||||
|
|
||||||
|
The ``ansible-hardening`` role is applicable to physical hosts within
|
||||||
|
an OpenStack-Ansible deployment
|
||||||
|
that are operating as any type of node, infrastructure or compute. By
|
||||||
|
default, the role is enabled. You can disable it by changing the value of
|
||||||
|
the ``apply_security_hardening`` variable in the ``user_variables.yml`` file
|
||||||
|
to ``false``:
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
apply_security_hardening: false
|
||||||
|
|
||||||
|
You can apply security hardening configurations to an existing environment or
|
||||||
|
audit an environment by using a playbook supplied with OpenStack-Ansible:
|
||||||
|
|
||||||
|
.. code-block:: bash
|
||||||
|
|
||||||
|
# Apply security hardening configurations
|
||||||
|
openstack-ansible security-hardening.yml
|
||||||
|
|
||||||
|
# Perform a quick audit by using Ansible's check mode
|
||||||
|
openstack-ansible --check security-hardening.yml
|
||||||
|
|
||||||
|
For more information about the security configurations, see the
|
||||||
|
`security hardening role`_ documentation.
|
||||||
|
|
||||||
|
.. _security hardening role: http://docs.openstack.org/developer/ansible-hardening/
|
12
doc/source/user/security/index.rst
Normal file
@ -0,0 +1,12 @@
|
|||||||
|
=================
|
||||||
|
Security settings
|
||||||
|
=================
|
||||||
|
|
||||||
|
This chapter contains information to configure specific security
|
||||||
|
settings for your OpenStack-Ansible cloud.
|
||||||
|
|
||||||
|
For understanding security design, please see
|
||||||
|
:ref:`security-design`.
|
||||||
|
|
||||||
|
.. include:: ssl-certificates.rst
|
||||||
|
.. include:: hardening.rst
|
@ -1,4 +1,3 @@
|
|||||||
=======================================
|
|
||||||
Securing services with SSL certificates
|
Securing services with SSL certificates
|
||||||
=======================================
|
=======================================
|
||||||
|
|
||||||
@ -12,24 +11,17 @@ communication between services:
|
|||||||
All public endpoints reside behind haproxy, resulting in the only certificate
|
All public endpoints reside behind haproxy, resulting in the only certificate
|
||||||
management most environments need are those for haproxy.
|
management most environments need are those for haproxy.
|
||||||
|
|
||||||
When deploying with OpenStack-Ansible, you can either use self-signed certificates
|
When deploying with OpenStack-Ansible, you can either use self-signed
|
||||||
that are generated during the deployment process or provide SSL certificates,
|
certificates that are generated during the deployment process or provide
|
||||||
keys, and CA certificates from your own trusted certificate authority. Highly
|
SSL certificates, keys, and CA certificates from your own trusted
|
||||||
secured environments use trusted, user-provided certificates for as
|
certificate authority. Highly secured environments use trusted,
|
||||||
many services as possible.
|
user-provided certificates for as many services as possible.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
Perform all SSL certificate configuration in
|
Perform all SSL certificate configuration in
|
||||||
``/etc/openstack_deploy/user_variables.yml`` file and not in the playbooks
|
``/etc/openstack_deploy/user_variables.yml`` file. Do not edit the playbooks
|
||||||
or roles themselves. The variables to set which provide the path on the deployment
|
or roles themselves.
|
||||||
node to the certificates for HAProxy configuration are:
|
|
||||||
|
|
||||||
.. code-block:: yaml
|
|
||||||
|
|
||||||
haproxy_user_ssl_cert: /etc/openstack_deploy/ssl/example.com.crt
|
|
||||||
haproxy_user_ssl_key: /etc/openstack_deploy/ssl/example.com.key
|
|
||||||
haproxy_user_ssl_ca_cert: /etc/openstack_deploy/ssl/ExampleCA.crt
|
|
||||||
|
|
||||||
Self-signed certificates
|
Self-signed certificates
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
@ -113,7 +105,22 @@ OpenStack-Ansible:
|
|||||||
the ``/etc/openstack_deploy/user_variables.yml`` file.
|
the ``/etc/openstack_deploy/user_variables.yml`` file.
|
||||||
#. Run the playbook for that service.
|
#. Run the playbook for that service.
|
||||||
|
|
||||||
For example, to deploy user-provided certificates for RabbitMQ,
|
HAProxy example
|
||||||
|
---------------
|
||||||
|
|
||||||
|
The variables to set which provide the path on the deployment
|
||||||
|
node to the certificates for HAProxy configuration are:
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
haproxy_user_ssl_cert: /etc/openstack_deploy/ssl/example.com.crt
|
||||||
|
haproxy_user_ssl_key: /etc/openstack_deploy/ssl/example.com.key
|
||||||
|
haproxy_user_ssl_ca_cert: /etc/openstack_deploy/ssl/ExampleCA.crt
|
||||||
|
|
||||||
|
RabbitMQ example
|
||||||
|
----------------
|
||||||
|
|
||||||
|
To deploy user-provided certificates for RabbitMQ,
|
||||||
copy the certificates to the deployment host, edit
|
copy the certificates to the deployment host, edit
|
||||||
the ``/etc/openstack_deploy/user_variables.yml`` file and set the following
|
the ``/etc/openstack_deploy/user_variables.yml`` file and set the following
|
||||||
three variables:
|
three variables:
|
@ -1,13 +1,8 @@
|
|||||||
.. _test-environment-config:
|
========================
|
||||||
|
Test environment example
|
||||||
|
========================
|
||||||
|
|
||||||
==================================================
|
Here is an example test environment for a working
|
||||||
Appendix A: Example test environment configuration
|
|
||||||
==================================================
|
|
||||||
|
|
||||||
Introduction
|
|
||||||
~~~~~~~~~~~~
|
|
||||||
|
|
||||||
This appendix describes an example test environment for a working
|
|
||||||
OpenStack-Ansible (OSA) deployment with a small number of servers.
|
OpenStack-Ansible (OSA) deployment with a small number of servers.
|
||||||
|
|
||||||
This example environment has the following characteristics:
|
This example environment has the following characteristics:
|
||||||
@ -20,7 +15,7 @@ This example environment has the following characteristics:
|
|||||||
* Internet access via the router address 172.29.236.1 on the
|
* Internet access via the router address 172.29.236.1 on the
|
||||||
Management Network
|
Management Network
|
||||||
|
|
||||||
.. image:: figures/arch-layout-test.png
|
.. image:: ../figures/arch-layout-test.png
|
||||||
:width: 100%
|
:width: 100%
|
||||||
:alt: Test environment host layout
|
:alt: Test environment host layout
|
||||||
|
|
||||||
@ -71,7 +66,7 @@ following is the ``/etc/network/interfaces`` file for ``infra1``.
|
|||||||
configuration files are replaced with the appropriate name. The same
|
configuration files are replaced with the appropriate name. The same
|
||||||
applies to additional network interfaces.
|
applies to additional network interfaces.
|
||||||
|
|
||||||
.. literalinclude:: ../../etc/network/interfaces.d/openstack_interface.cfg.test.example
|
.. literalinclude:: ../../../../etc/network/interfaces.d/openstack_interface.cfg.test.example
|
||||||
|
|
||||||
Deployment configuration
|
Deployment configuration
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
@ -84,7 +79,7 @@ environment layout.
|
|||||||
|
|
||||||
The following configuration describes the layout for this environment.
|
The following configuration describes the layout for this environment.
|
||||||
|
|
||||||
.. literalinclude:: ../../etc/openstack_deploy/openstack_user_config.yml.test.example
|
.. literalinclude:: ../../../../etc/openstack_deploy/openstack_user_config.yml.test.example
|
||||||
|
|
||||||
Environment customizations
|
Environment customizations
|
||||||
--------------------------
|
--------------------------
|
||||||
@ -103,10 +98,10 @@ User variables
|
|||||||
The ``/etc/openstack_deploy/user_variables.yml`` file defines the global
|
The ``/etc/openstack_deploy/user_variables.yml`` file defines the global
|
||||||
overrides for the default variables.
|
overrides for the default variables.
|
||||||
|
|
||||||
For this environment, you are using the same IP address for the internal
|
For this environment, if you want to use the same IP address for the internal
|
||||||
and external endpoints. You will need to ensure that the internal and public
|
and external endpoints, you will need to ensure that the internal and public
|
||||||
OpenStack endpoints are served with the same protocol. This is done with
|
OpenStack endpoints are served with the same protocol. This is done with
|
||||||
the following content:
|
the following content:
|
||||||
|
|
||||||
.. literalinclude:: ../../etc/openstack_deploy/user_variables.yml.test.example
|
.. literalinclude:: ../../../../etc/openstack_deploy/user_variables.yml.test.example
|
||||||
|
|