Fix 'D002 Trailing whitespace' doc errors
Change-Id: Ifd9c10cbf1ad54afc1e88cc167503569b8d9bc2c
This commit is contained in:
Jesse Pretorius
parent
5487d57f15
commit
89d82b00fd
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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**
|
||||
|
||||
|
||||
@ -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:
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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**
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user