From 37cef1030d31852f5702ed6bd579be6aa0e42090 Mon Sep 17 00:00:00 2001
From: caoyuan <cao.yuan@99cloud.net>
Date: Sat, 17 Sep 2016 00:33:00 +0000
Subject: [PATCH] Remove the unnecessary space
TrivialFix
Change-Id: I7c0eee966b6d016c715c350a285ed8e21a5fc9b0
---
doc/advanced-configuration.rst | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/doc/advanced-configuration.rst b/doc/advanced-configuration.rst
index c5180534e7..a91c01afeb 100644
--- a/doc/advanced-configuration.rst
+++ b/doc/advanced-configuration.rst
@@ -8,12 +8,12 @@ Endpoint Network Configuration
==============================
When an OpenStack cloud is deployed, each services' REST API is presented
-as a series of endpoints. These endpoints are the admin URL, the internal
+as a series of endpoints. These endpoints are the admin URL, the internal
URL, and the external URL.
Kolla offers two options for assigning these endpoints to network addresses.
-These are combined and separate. For the combined option, all three
-endpoints share the same IP address. For the separate option, the external
+These are combined and separate. For the combined option, all three
+endpoints share the same IP address. For the separate option, the external
URL is assigned to an IP address that is different than the IP address
shared by the internal and admin URLs.
@@ -24,13 +24,13 @@ The configuration parameters related to these options are:
- kolla_external_vip_interface
For the combined option, set the two variables below, while allowing the
-other two to accept their default values. In this configuration all REST
+other two to accept their default values. In this configuration all REST
API requests, internal and external, will flow over the same network. ::
kolla_internal_vip_address: "10.10.10.254"
network_interface: "eth0"
-For the separate option, set these four variables. In this configuration
+For the separate option, set these four variables. In this configuration
the internal and external REST API requests can flow over separate
networks. ::
@@ -56,14 +56,14 @@ deployment use the variables:
kolla_external_fqdn: mykolla.example.net
Provisions must be taken outside of kolla for these names to map to the
-configured IP addresses. Using a DNS server or the /etc/hosts file are
+configured IP addresses. Using a DNS server or the /etc/hosts file are
two ways to create this mapping.
TLS Configuration
=================
An additional endpoint configuration option is to enable or disable
-TLS protection for the external VIP. TLS allows a client to authenticate
+TLS protection for the external VIP. TLS allows a client to authenticate
the OpenStack service endpoint and allows for encryption of the requests
and responses.
@@ -84,20 +84,20 @@ The default for TLS is disabled; to enable TLS networking:
.. note:: TLS authentication is based on certificates that have been
- signed by trusted Certificate Authorities. Examples of commercial
- CAs are Comodo, Symantec, GoDaddy, and GlobalSign. Letsencrypt.org
+ signed by trusted Certificate Authorities. Examples of commercial
+ CAs are Comodo, Symantec, GoDaddy, and GlobalSign. Letsencrypt.org
is a CA that will provide trusted certificates at no charge. Many
company's IT departments will provide certificates within that
- company's domain. If using a trusted CA is not possible for your
+ company's domain. If using a trusted CA is not possible for your
situation, you can use OpenSSL to create your own or see the section
below about kolla generated self-signed certificates.
Two certificate files are required to use TLS securely with authentication.
-These two files will be provided by your Certificate Authority. These
+These two files will be provided by your Certificate Authority. These
two files are the server certificate with private key and the CA certificate
-with any intermediate certificates. The server certificate needs to be
+with any intermediate certificates. The server certificate needs to be
installed with the kolla deployment and is configured with the
-``kolla_external_fqdn_cert`` parameter. If the server certificate provided
+``kolla_external_fqdn_cert`` parameter. If the server certificate provided
is not already trusted by the client, then the CA certificate file will
need to be distributed to the client.
@@ -122,7 +122,7 @@ Self-Signed Certificates
.. note:: Self-signed certificates should never be used in production.
It is not always practical to get a certificate signed by a well-known
-trust CA, for example a development or internal test kolla deployment. In
+trust CA, for example a development or internal test kolla deployment. In
these cases it can be useful to have a self-signed certificate to use.
For convenience, the kolla-ansible command will generate the necessary