openstack/kolla
Code Issues Proposed changes

Remove the unnecessary space

Browse Source 
TrivialFix

Change-Id: I7c0eee966b6d016c715c350a285ed8e21a5fc9b0
This commit is contained in:
caoyuan 2016-09-17 00:33:00 +00:00
parent d75847772d
commit 37cef1030d
1 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
doc/advanced-configuration.rst
View File

@ -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