Update docs structure according to document structure guide

According to the document structure, feature projects are
expected to store their documentation as following,

<repo>/docs/userguide/feature.usage.rst
<repo>/docs/userguide/index.rst
<repo>/docs/installationprocedure/feature.configuration.rst
<repo>/docs/installationprocedure/index.rst

And as per previous release,
<repo>/docs/releasenotes/release.notes.rst
<repo>/docs/releasenotes/index.rst

In multisite repo that we have both an installation instruction
and a config guide. Need to combine these and then store them in
<repo>/docs/installationprocedure/feature.configuration.rst

And add release notes.

Change-Id: I9ba0663640063488e232b1342174b10266ac77fc
Signed-off-by: joehuang <joehuang@huawei.com>

1 files changed, 0 insertions, 110 deletions

diff --git a/docs/configurationguide/multisite-configuration-guide.rst b/docs/configurationguide/multisite-configuration-guide.rst
deleted file mode 100644
index c005e8d..0000000
--- a/docs/configurationguide/multisite-configuration-guide.rst
+++ /dev/null
@@ -1,110 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-
-=============================
-Multisite configuration guide
-=============================
-
-Multisite identity service management
-=====================================
-
-Goal
-----
-
-A user should, using a single authentication point be able to manage virtual
-resources spread over multiple OpenStack regions.
-
-Before you read
----------------
-
-This chapter does not intend to cover all configuration of KeyStone and other
-OpenStack services to work together with KeyStone.
-
-This chapter focuses only on the configuration part should be taken into
-account in multi-site scenario.
-
-Please read the configuration documentation related to identity management
-of OpenStack for all configuration items.
-
-http://docs.openstack.org/liberty/config-reference/content/ch_configuring-openstack-identity.html
-
-How to configure the database cluster for synchronization or asynchrounous
-repliation in multi-site scenario is out of scope of this document. The only
-remainder is that for the synchronization or replication, only Keystone
-database is required. If you are using MySQL, you can configure like this:
-
-In the master:
-
-   .. code-block:: bash
-
-      binlog-do-db=keystone
-
-In the slave:
-
-   .. code-block:: bash
-
-      replicate-do-db=keystone
-
-
-Deployment options
-------------------
-
-For each detail description of each deployment option, please refer to the
-admin-user-guide.
-
--  Distributed KeyStone service with PKI token
-
-   In KeyStone configuration file, PKI token format should be configured
-
-   .. code-block:: bash
-
-      provider = pki
-
-   or
-
-   .. code-block:: bash
-
-      provider = pkiz
-
-   In the [keystone_authtoken] section of each OpenStack service configuration
-   file in each site, configure the identity_url and auth_uri to the address
-   of KeyStone service
-
-   .. code-block:: bash
-
-      identity_uri = https://keystone.your.com:35357/
-      auth_uri = http://keystone.your.com:5000/v2.0
-
-   It's better to use domain name for the KeyStone service, but not to use IP
-   address directly, especially if you deployed KeyStone service in at least
-   two sites for site level high availability.
-
--  Distributed KeyStone service with Fernet token
--  Distributed KeyStone service with Fernet token + Async replication (
-   star-mode).
-
-   In these two deployment options, the token validation is planned to be done
-   in local site.
-
-   In KeyStone configuration file, Fernet token format should be configured
-
-   .. code-block:: bash
-
-      provider = fernet
-
-   In the [keystone_authtoken] section of each OpenStack service configuration
-   file in each site, configure the identity_url and auth_uri to the address
-   of local KeyStone service
-
-   .. code-block:: bash
-
-      identity_uri = https://local-keystone.your.com:35357/
-      auth_uri = http://local-keystone.your.com:5000/v2.0
-
-   and especially, configure the region_name to your local region name, for
-   example, if you are configuring services in RegionOne, and there is local
-   KeyStone service in RegionOne, then
-
-   .. code-block:: bash
-
-      region_name = RegionOne