diff --git a/doc/source/developer-docs/configure-aodh.rst b/doc/source/developer-docs/configure-aodh.rst index 67dae46234..c97dc36297 100644 --- a/doc/source/developer-docs/configure-aodh.rst +++ b/doc/source/developer-docs/configure-aodh.rst @@ -71,7 +71,7 @@ Setting up a MongoDB database for Aodh .. note:: - + Ensure ``AODH_DBPASS`` matches the ``aodh_container_db_password`` in the ``/etc/openstack_deploy/user_secrets.yml`` file. This diff --git a/doc/source/developer-docs/configure-ceilometer.rst b/doc/source/developer-docs/configure-ceilometer.rst index 86d7866eee..ba2cdf3765 100644 --- a/doc/source/developer-docs/configure-ceilometer.rst +++ b/doc/source/developer-docs/configure-ceilometer.rst @@ -18,7 +18,7 @@ The Telemetry module (ceilometer) performs the following functions: services. For configuring these services, see the aodh docs: http://docs.openstack.org/developer/aodh/ -Configure a MongoDB backend prior to running the ceilometer playbooks. +Configure a MongoDB backend prior to running the ceilometer playbooks. The connection data is in the ``user_variables.yml`` file (see section `Configuring the user data`_ below). @@ -74,7 +74,7 @@ Setting up a MongoDB database for ceilometer } .. note:: - + Ensure ``CEILOMETER_DBPASS`` matches the ``ceilometer_container_db_password`` in the ``/etc/openstack_deploy/user_secrets.yml`` file. This is diff --git a/doc/source/developer-docs/configure-federation-sp-overview.rst b/doc/source/developer-docs/configure-federation-sp-overview.rst index 4221fd3ee6..b4c25f546b 100644 --- a/doc/source/developer-docs/configure-federation-sp-overview.rst +++ b/doc/source/developer-docs/configure-federation-sp-overview.rst @@ -19,7 +19,7 @@ When requests are sent to those locations, Apache hands off the request to the ``shibd`` service. .. note:: - + Handing off happens only with requests pertaining to authentication. Handle the ``shibd`` service configuration through diff --git a/doc/source/developer-docs/configure-federation-sp.rst b/doc/source/developer-docs/configure-federation-sp.rst index 6a14117441..facc04fb73 100644 --- a/doc/source/developer-docs/configure-federation-sp.rst +++ b/doc/source/developer-docs/configure-federation-sp.rst @@ -19,7 +19,7 @@ The following settings must be set to configure a service provider (SP): keystone endpoint if the IdP is ADFS. Keystone or an SSL offloading load balancer provides the endpoint. -#. Set ``keystone_service_publicuri_proto`` to https. +#. Set ``keystone_service_publicuri_proto`` to https. This ensures keystone publishes https in its references and ensures that Shibboleth is configured to know that it expects SSL URL's in the assertions (otherwise it will invalidate diff --git a/doc/source/developer-docs/configure-federation-use-case.rst b/doc/source/developer-docs/configure-federation-use-case.rst index 0c97bdeb12..f10303a9d8 100644 --- a/doc/source/developer-docs/configure-federation-use-case.rst +++ b/doc/source/developer-docs/configure-federation-use-case.rst @@ -150,10 +150,10 @@ The ``local`` part of the mapping rule specifies how keystone represents the remote user in the local SP cloud. Configuring the two federated identities with their own user group maps the user to the corresponding group. This exposes the correct domain, project, and -role. +role. .. note:: - + Keystone creates a ephemeral user in the specified group as you cannot specify user names. diff --git a/doc/source/developer-docs/configure-keystone.rst b/doc/source/developer-docs/configure-keystone.rst index 93b75e8938..4033a1bded 100644 --- a/doc/source/developer-docs/configure-keystone.rst +++ b/doc/source/developer-docs/configure-keystone.rst @@ -38,7 +38,7 @@ Implementing LDAP (or Active Directory) backends ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ You can use the built-in keystone support for services if you already have -LDAP or Active Directory (AD) infrastructure on your deployment. +LDAP or Active Directory (AD) infrastructure on your deployment. Keystone uses the existing users, groups, and user-group relationships to handle authentication and access control in an OpenStack deployment. @@ -47,8 +47,8 @@ handle authentication and access control in an OpenStack deployment. We do not recommend configuring the default domain in keystone to use LDAP or AD identity backends. Create additional domains in keystone and configure either LDAP or active directory backends for - that domain. - + that domain. + This is critical in situations where the identity backend cannot be reached due to network issues or other problems. In those situations, the administrative users in the default domain would still be able to diff --git a/doc/source/developer-docs/configure-swift-glance.rst b/doc/source/developer-docs/configure-swift-glance.rst index a679f63d67..e3cb8d9906 100644 --- a/doc/source/developer-docs/configure-swift-glance.rst +++ b/doc/source/developer-docs/configure-swift-glance.rst @@ -10,7 +10,7 @@ If there is an existing glance backend (for example, cloud files) but you want to add swift to use as the glance backend, you can re-add any images from glance after moving to swift. Images are no longer available if there is a change in the -glance variables when you begin using swift. +glance variables when you begin using swift. **Procedure 5.3. Integrating Object Storage with Image Service** diff --git a/doc/source/developer-docs/deploy-config.rst b/doc/source/developer-docs/deploy-config.rst index afda3be9de..e1a7037f4e 100644 --- a/doc/source/developer-docs/deploy-config.rst +++ b/doc/source/developer-docs/deploy-config.rst @@ -4,7 +4,7 @@ Deployment configuration options Ansible references a handful of files containing mandatory and optional configuration directives. This chapter describes optional configuration -options to define the target environment before running the Ansible playbooks. +options to define the target environment before running the Ansible playbooks. Contents: diff --git a/doc/source/install-guide-revised-draft/app-plumgrid.rst b/doc/source/install-guide-revised-draft/app-plumgrid.rst index 472568618f..8b62176976 100644 --- a/doc/source/install-guide-revised-draft/app-plumgrid.rst +++ b/doc/source/install-guide-revised-draft/app-plumgrid.rst @@ -78,10 +78,10 @@ following parameters. pg_vip: PG_VIP #. Replace ``FABRIC_IFC`` with the name of the interface that will be used - for PLUMgrid Fabric. - + for PLUMgrid Fabric. + .. note:: - + PLUMgrid Fabric must be an untagged unbridged raw interface such as ``eth0``. .. code-block:: yaml @@ -121,9 +121,9 @@ to as ``gateway_devs`` in the configuration files. #. Add a ``gateway_hosts`` section to the end of the PLUMgrid ``user_pg_vars.yml`` file: - + .. note:: - + This must contain hostnames and ``gateway_dev`` names for each gateway in the cluster. diff --git a/doc/source/install-guide-revised-draft/overview-host-layout.rst b/doc/source/install-guide-revised-draft/overview-host-layout.rst index 2e31c2450e..a6b83af797 100644 --- a/doc/source/install-guide-revised-draft/overview-host-layout.rst +++ b/doc/source/install-guide-revised-draft/overview-host-layout.rst @@ -80,7 +80,7 @@ It also has the following features: - No log aggregation target host - File-backed storage for glance and nova - LVM-backed cinder - + .. image:: figures/arch-layout-test.png :width: 100% :alt: Test environment host layout diff --git a/doc/source/install-guide-revised-draft/overview-requirements.rst b/doc/source/install-guide-revised-draft/overview-requirements.rst index 7922f78874..c67e16920c 100644 --- a/doc/source/install-guide-revised-draft/overview-requirements.rst +++ b/doc/source/install-guide-revised-draft/overview-requirements.rst @@ -62,7 +62,7 @@ Logging hosts log traffic coming from various hosts and containers within the OpenStack environment. Reserve a minimum of 50GB of disk space for storing logs on the logging hosts. - + Hosts that provide Block Storage (cinder) volumes must have logical volume manager (LVM) support. Ensure those hosts have a ``cinder-volumes`` volume group that OpenStack-Ansible can configure for use with cinder. diff --git a/doc/source/install-guide-revised-draft/targethosts-prepare.rst b/doc/source/install-guide-revised-draft/targethosts-prepare.rst index 57d16eb7c7..45a8b1dcfd 100644 --- a/doc/source/install-guide-revised-draft/targethosts-prepare.rst +++ b/doc/source/install-guide-revised-draft/targethosts-prepare.rst @@ -5,14 +5,14 @@ Preparing the target hosts ========================== The following section describes the installation and configuration of -operating systems for the target hosts. +operating systems for the target hosts. Installing the operating system ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Install the Ubuntu Server 14.04 (Trusty Tahr) LTS 64-bit operating system on the target host. Configure at least one network interface -to access the internet or suitable local repositories. +to access the internet or suitable local repositories. We recommend adding the Secure Shell (SSH) server packages to the installation on target hosts without local (console) access. diff --git a/doc/source/install-guide/app-plumgrid.rst b/doc/source/install-guide/app-plumgrid.rst index 7127c050f9..25b5a25eca 100644 --- a/doc/source/install-guide/app-plumgrid.rst +++ b/doc/source/install-guide/app-plumgrid.rst @@ -78,10 +78,10 @@ following parameters. pg_vip: PG_VIP #. Replace ``FABRIC_IFC`` with the name of the interface that will be used - for PLUMgrid Fabric. - + for PLUMgrid Fabric. + .. note:: - + PLUMgrid Fabric must be an untagged unbridged raw interface such as ``eth0``. .. code-block:: yaml @@ -121,9 +121,9 @@ to as ``gateway_devs`` in the configuration files. #. Add a ``gateway_hosts`` section to the end of the PLUMgrid ``user_pg_vars.yml`` file: - + .. note:: - + This must contain hostnames and ``gateway_dev`` names for each gateway in the cluster. diff --git a/doc/source/install-guide/configure-ceilometer.rst b/doc/source/install-guide/configure-ceilometer.rst index 86d7866eee..ba2cdf3765 100644 --- a/doc/source/install-guide/configure-ceilometer.rst +++ b/doc/source/install-guide/configure-ceilometer.rst @@ -18,7 +18,7 @@ The Telemetry module (ceilometer) performs the following functions: services. For configuring these services, see the aodh docs: http://docs.openstack.org/developer/aodh/ -Configure a MongoDB backend prior to running the ceilometer playbooks. +Configure a MongoDB backend prior to running the ceilometer playbooks. The connection data is in the ``user_variables.yml`` file (see section `Configuring the user data`_ below). @@ -74,7 +74,7 @@ Setting up a MongoDB database for ceilometer } .. note:: - + Ensure ``CEILOMETER_DBPASS`` matches the ``ceilometer_container_db_password`` in the ``/etc/openstack_deploy/user_secrets.yml`` file. This is diff --git a/doc/source/install-guide/configure-federation-sp-overview.rst b/doc/source/install-guide/configure-federation-sp-overview.rst index 870aa28ee1..8a141261e7 100644 --- a/doc/source/install-guide/configure-federation-sp-overview.rst +++ b/doc/source/install-guide/configure-federation-sp-overview.rst @@ -19,7 +19,7 @@ When requests are sent to those locations, Apache hands off the request to the ``shibd`` service. .. note:: - + Handing off happens only with requests pertaining to authentication. Handle the ``shibd`` service configuration through diff --git a/doc/source/install-guide/configure-federation-sp.rst b/doc/source/install-guide/configure-federation-sp.rst index 6a14117441..facc04fb73 100644 --- a/doc/source/install-guide/configure-federation-sp.rst +++ b/doc/source/install-guide/configure-federation-sp.rst @@ -19,7 +19,7 @@ The following settings must be set to configure a service provider (SP): keystone endpoint if the IdP is ADFS. Keystone or an SSL offloading load balancer provides the endpoint. -#. Set ``keystone_service_publicuri_proto`` to https. +#. Set ``keystone_service_publicuri_proto`` to https. This ensures keystone publishes https in its references and ensures that Shibboleth is configured to know that it expects SSL URL's in the assertions (otherwise it will invalidate diff --git a/doc/source/install-guide/configure-federation-use-case.rst b/doc/source/install-guide/configure-federation-use-case.rst index 0c97bdeb12..f10303a9d8 100644 --- a/doc/source/install-guide/configure-federation-use-case.rst +++ b/doc/source/install-guide/configure-federation-use-case.rst @@ -150,10 +150,10 @@ The ``local`` part of the mapping rule specifies how keystone represents the remote user in the local SP cloud. Configuring the two federated identities with their own user group maps the user to the corresponding group. This exposes the correct domain, project, and -role. +role. .. note:: - + Keystone creates a ephemeral user in the specified group as you cannot specify user names. diff --git a/doc/source/install-guide/configure-keystone.rst b/doc/source/install-guide/configure-keystone.rst index 93b75e8938..4033a1bded 100644 --- a/doc/source/install-guide/configure-keystone.rst +++ b/doc/source/install-guide/configure-keystone.rst @@ -38,7 +38,7 @@ Implementing LDAP (or Active Directory) backends ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ You can use the built-in keystone support for services if you already have -LDAP or Active Directory (AD) infrastructure on your deployment. +LDAP or Active Directory (AD) infrastructure on your deployment. Keystone uses the existing users, groups, and user-group relationships to handle authentication and access control in an OpenStack deployment. @@ -47,8 +47,8 @@ handle authentication and access control in an OpenStack deployment. We do not recommend configuring the default domain in keystone to use LDAP or AD identity backends. Create additional domains in keystone and configure either LDAP or active directory backends for - that domain. - + that domain. + This is critical in situations where the identity backend cannot be reached due to network issues or other problems. In those situations, the administrative users in the default domain would still be able to diff --git a/doc/source/install-guide/configure-swift-glance.rst b/doc/source/install-guide/configure-swift-glance.rst index a679f63d67..e3cb8d9906 100644 --- a/doc/source/install-guide/configure-swift-glance.rst +++ b/doc/source/install-guide/configure-swift-glance.rst @@ -10,7 +10,7 @@ If there is an existing glance backend (for example, cloud files) but you want to add swift to use as the glance backend, you can re-add any images from glance after moving to swift. Images are no longer available if there is a change in the -glance variables when you begin using swift. +glance variables when you begin using swift. **Procedure 5.3. Integrating Object Storage with Image Service** diff --git a/doc/source/install-guide/overview-requirements.rst b/doc/source/install-guide/overview-requirements.rst index e8e9545d5e..bd19e19b95 100644 --- a/doc/source/install-guide/overview-requirements.rst +++ b/doc/source/install-guide/overview-requirements.rst @@ -60,9 +60,9 @@ Logging hosts In addition, the storage performance must be enough to keep pace with the log traffic coming from various hosts and containers within the OpenStack environment. Reserve a minimum of 50GB of disk space for storing - logs on the logging hosts. + logs on the logging hosts. + - Hosts that provide Block Storage (cinder) volumes must have logical volume manager (LVM) support. Ensure those hosts have a ``cinder-volumes`` volume group that OpenStack-Ansible can configure for use with cinder. diff --git a/doc/source/install-guide/overview-security.rst b/doc/source/install-guide/overview-security.rst index a8297dda2c..b6345dd0d0 100644 --- a/doc/source/install-guide/overview-security.rst +++ b/doc/source/install-guide/overview-security.rst @@ -75,10 +75,10 @@ Securing network access to OpenStack services ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ OpenStack environments expose many service ports and API endpoints to the -network. +network. .. note:: - + Deployers must limit access to these resources and expose them only to trusted users and networks. diff --git a/doc/source/install-guide/targethosts-prepare.rst b/doc/source/install-guide/targethosts-prepare.rst index 57d16eb7c7..45a8b1dcfd 100644 --- a/doc/source/install-guide/targethosts-prepare.rst +++ b/doc/source/install-guide/targethosts-prepare.rst @@ -5,14 +5,14 @@ Preparing the target hosts ========================== The following section describes the installation and configuration of -operating systems for the target hosts. +operating systems for the target hosts. Installing the operating system ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Install the Ubuntu Server 14.04 (Trusty Tahr) LTS 64-bit operating system on the target host. Configure at least one network interface -to access the internet or suitable local repositories. +to access the internet or suitable local repositories. We recommend adding the Secure Shell (SSH) server packages to the installation on target hosts without local (console) access.