From a972884d169c32e4a12eef21ea58bd38c3df37f4 Mon Sep 17 00:00:00 2001 From: KATO Tomoyuki Date: Wed, 28 Sep 2016 18:43:15 +0900 Subject: [PATCH] Fix incorrect RST markups also, remove improper internal reference target. Change-Id: I49c969eab536e3a40c7a7b05481982e5d0cdb75c --- .../source/use-cases/use-case-multisite.rst | 15 ++++--------- .../source/shared-database-configure.rst | 22 +++++++++---------- 2 files changed, 15 insertions(+), 22 deletions(-) diff --git a/doc/arch-design-draft/source/use-cases/use-case-multisite.rst b/doc/arch-design-draft/source/use-cases/use-case-multisite.rst index 984efc8ebd..375ebc9638 100644 --- a/doc/arch-design-draft/source/use-cases/use-case-multisite.rst +++ b/doc/arch-design-draft/source/use-cases/use-case-multisite.rst @@ -81,12 +81,10 @@ The follow figure depicts the solution designed to have both a centralized set of core data centers for OpenStack services and paired edge data centers. - - **Multi-site architecture example** +**Multi-site architecture example** .. figure:: ../figures/Multi-Site_Customer_Edge.png - Geo-redundant load balancing example ------------------------------------ @@ -166,13 +164,10 @@ An external load balancing service was used and not the LBaaS in OpenStack because the solution in OpenStack is not redundant and does not have any awareness of geo location. -.. _ms-geo-redundant: - - **Multi-site geo-redundant architecture** +**Multi-site geo-redundant architecture** .. figure:: ../figures/Multi-site_Geo_Redundant_LB.png - Location-local service example ------------------------------ @@ -192,15 +187,13 @@ number of network hops for end users. Despite these differences, the storage replication configuration has significant overlap with that of a geo-redundant load balancing use case. -In :ref:`ms-shared-keystone`, the application utilizing this multi-site +In the below architecture, the application utilizing this multi-site OpenStack install that is location-aware would launch web server or content serving instances on the compute cluster in each site. Requests from clients are first sent to a global services load balancer that determines the location of the client, then routes the request to the closest OpenStack site where the application completes the request. -.. _ms-shared-keystone: +**Multi-site shared keystone architecture** .. figure:: ../figures/Multi-Site_shared_keystone1.png - - **Multi-site shared keystone architecture** diff --git a/doc/ha-guide/source/shared-database-configure.rst b/doc/ha-guide/source/shared-database-configure.rst index 011da28f24..6da800d9ca 100644 --- a/doc/ha-guide/source/shared-database-configure.rst +++ b/doc/ha-guide/source/shared-database-configure.rst @@ -33,11 +33,11 @@ Galera Cluster requires that you open four ports to network traffic: This can be achieved through the use of either the ``iptables`` command such as: - .. code-block:: console +.. code-block:: console - # iptables --append INPUT --in-interface eth0 \ - --protocol tcp --match tcp --dport ${PORT} \ - --source ${NODE-IP-ADDRESS} --jump ACCEPT + # iptables --append INPUT --in-interface eth0 \ + --protocol tcp --match tcp --dport ${PORT} \ + --source ${NODE-IP-ADDRESS} --jump ACCEPT Make sure to save the changes once you are done, this will vary depending on your distribution: @@ -49,10 +49,10 @@ Alternatively you may be able to make modifications using the ``firewall-cmd`` utility for FirewallD that is available on many Linux distributions: - .. code-block:: console +.. code-block:: console - # firewall-cmd --add-service=mysql --permanent - # firewall-cmd --add-port=3306/tcp --permanent + # firewall-cmd --add-service=mysql --permanent + # firewall-cmd --add-port=3306/tcp --permanent SELinux -------- @@ -67,17 +67,17 @@ To configure SELinux to permit Galera Cluster to operate, you may need to use the ``semanage`` utility to open the ports it uses, for example: - .. code-block:: console +.. code-block:: console - # semanage port -a -t mysqld_port_t -p tcp 3306 + # semanage port -a -t mysqld_port_t -p tcp 3306 Older versions of some distributions, which do not have an up-to-date policy for securing Galera, may also require SELinux to be more relaxed about database access and actions: - .. code-block:: console +.. code-block:: console - # semanage permissive -a mysqld_t + # semanage permissive -a mysqld_t .. note:: Bear in mind, leaving SELinux in permissive mode is not a good security practice. Over the longer term, you need to develop a