New "logical architecture" page in cloud admin guide

The text on this page seems to be copied directly from a
developer guide and is largely irrelevant for admins.
Text must be rewritten, and the diagram, which depicts
the situation at Havana time, must be redrawn.

Change-Id: I8f0a9538661292619bd8375ae03d20fe3cee2b5e
Closes-Bug: #1431079

doc/common/section_getstart_logical_arch.xml

@@ -6,30 +6,39 @@
   xml:id="logical-architecture">
   <title>Logical architecture</title>
   <para>To design, deploy, and configure OpenStack, administrators must understand the logical architecture.</para>
-  <para>OpenStack modules are one of the following types:</para>
+
-  <variablelist>
+  <para>As shown in <xref linkend="concept_arch"/>, OpenStack consists of
-   <varlistentry><term>Daemon</term>
+  several
-    <listitem>
+  independent parts, named the OpenStack services.
-      <para>Runs as a background process. On Linux platforms, a daemon is
+  All services authenticate
-        usually installed as a service.</para>
+  through a common Identity service. Individual services interact
-    </listitem>
+  with each other through public APIs, except where privileged
-   </varlistentry>
+  administrator commands are necessary.</para>
-   <varlistentry><term>Script</term>
+
-    <listitem>
+  <para>Internally, OpenStack services are composed of several processes.
-      <para>Installs a virtual environment and runs tests. For
+  All services have at least one
-        example, the <code>run_tests.sh</code> script installs a virtual environment and runs unit tests on a service.</para>
+  API process, which listens for API requests, preprocesses them and
-    </listitem>
+  passes them on to other parts of the service. With the exception of
-   </varlistentry>
+  the Identity service, the actual work is done by distinct processes.</para>
-   <varlistentry><term>Command-line interface (CLI)</term>
+
-    <listitem>
+  <para>For communication between the processes of one service, an AMQP <glossterm>message
-      <para>Enables users to submit API
+  broker</glossterm> is used. The service's state is stored in a database.
-        calls to OpenStack services through easy-to-use
+  When deploying and configuring your OpenStack cloud, you can choose among
-        commands.</para>
+  several message broker and database solutions, such as
-    </listitem>
+  RabbitMQ, Qpid, MySQL, MariaDB, and SQLite.</para>
-   </varlistentry>
+
-  </variablelist>
+  <para>Users can access OpenStack via the web-based user interface implemented
-  <para>The following diagram shows the most common, but not the only,
+  by the <link linkend="ch_install-dashboard">dashboard service</link>,
-    architecture for an OpenStack cloud:</para>
+  via <link xlink:href="http://docs.openstack.org/cli-reference/content">command-line clients</link>
+  and by issuing API requests through tools like
+  browser plug-ins or <command>curl</command>. For applications,
+  <link xlink:href="http://developer.openstack.org/#sdk">several SDKs</link>
+  are available. Ultimately, all these access methods issue REST API
+  calls to the various OpenStack services.</para>
+
+  <para>The following diagram shows the most common, but not the only
+    possible, architecture for an OpenStack cloud:</para>
+
   <figure xml:id="os-logical-arch">
     <title>Logical architecture</title>
     <mediaobject>
@@ -40,9 +49,4 @@
       </imageobject>
     </mediaobject>
   </figure>
-  <para>As in <xref linkend="concept_arch"/>, end users can interact
-    through the dashboard, CLIs, and APIs. All services authenticate
-    through a common Identity Service and individual services interact
-    with each other through public APIs, except where privileged
-    administrator commands are necessary.</para>
 </section>