From 57fadeb3aae14be2ef99ba4a2472b2ba4a80cf05 Mon Sep 17 00:00:00 2001 From: Bernd Bausch Date: Wed, 6 May 2015 11:14:16 +0900 Subject: [PATCH] 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 | 62 +++++++++++--------- 1 file changed, 33 insertions(+), 29 deletions(-) diff --git a/doc/common/section_getstart_logical_arch.xml b/doc/common/section_getstart_logical_arch.xml index 8cc4c6104f..381467f131 100644 --- a/doc/common/section_getstart_logical_arch.xml +++ b/doc/common/section_getstart_logical_arch.xml @@ -6,30 +6,39 @@ xml:id="logical-architecture"> Logical architecture To design, deploy, and configure OpenStack, administrators must understand the logical architecture. - OpenStack modules are one of the following types: - - Daemon - - Runs as a background process. On Linux platforms, a daemon is - usually installed as a service. - - - Script - - Installs a virtual environment and runs tests. For - example, the run_tests.sh script installs a virtual environment and runs unit tests on a service. - - - Command-line interface (CLI) - - Enables users to submit API - calls to OpenStack services through easy-to-use - commands. - - - - The following diagram shows the most common, but not the only, - architecture for an OpenStack cloud: + + As shown in , OpenStack consists of + several + independent parts, named the OpenStack services. + All services authenticate + through a common Identity service. Individual services interact + with each other through public APIs, except where privileged + administrator commands are necessary. + + Internally, OpenStack services are composed of several processes. + All services have at least one + API process, which listens for API requests, preprocesses them and + passes them on to other parts of the service. With the exception of + the Identity service, the actual work is done by distinct processes. + + For communication between the processes of one service, an AMQP message + broker is used. The service's state is stored in a database. + When deploying and configuring your OpenStack cloud, you can choose among + several message broker and database solutions, such as + RabbitMQ, Qpid, MySQL, MariaDB, and SQLite. + + Users can access OpenStack via the web-based user interface implemented + by the dashboard service, + via command-line clients + and by issuing API requests through tools like + browser plug-ins or curl. For applications, + several SDKs + are available. Ultimately, all these access methods issue REST API + calls to the various OpenStack services. + + The following diagram shows the most common, but not the only + possible, architecture for an OpenStack cloud: +
Logical architecture @@ -40,9 +49,4 @@
- As in , 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.