From 66355045d239d8320222ebbb02b46adf12190f98 Mon Sep 17 00:00:00 2001 From: Lana Brindley Date: Thu, 22 Jan 2015 11:59:05 +1000 Subject: [PATCH] General updates to Compute for style and convention Editing the remainder of the compute chapter. Mostly grammar, wording, style, convention, etc. Partial-Bug: #1251195 # Please enter the commit message for your changes. Lines starting Change-Id: I92d3606c9630d4c3443fd1609afdfc91a56de3e1 --- doc/admin-guide-cloud/ch_compute.xml | 71 +++++++++++++++------------- 1 file changed, 39 insertions(+), 32 deletions(-) diff --git a/doc/admin-guide-cloud/ch_compute.xml b/doc/admin-guide-cloud/ch_compute.xml index 961b1aeec2..06c09a4187 100644 --- a/doc/admin-guide-cloud/ch_compute.xml +++ b/doc/admin-guide-cloud/ch_compute.xml @@ -143,7 +143,7 @@ For tenants, you can use quota controls to limit the: - Number of volumes that may be launched. + Number of volumes that can be launched. Number of processor cores and the amount of RAM that can be allocated. @@ -220,14 +220,17 @@ only one instance at a time, although you can detach and reattach volumes to as many different instances as you like. - You can configure persistent volumes as bootable and use them to provide a persistent - virtual instance similar to traditional non-cloud-based virtualization systems. - Typically, the resulting instance can also still have ephemeral storage depending on the - flavor selected, but the root file system can be on the persistent volume and its state - maintained even if the instance is shut down. For more information about this type of - configuration, see the - OpenStack Configuration Reference. + You can configure persistent volumes as bootable and use + them to provide a persistent virtual instance similar to + traditional non-cloud-based virtualization systems. + It is still possible for the resulting instance to also have + ephemeral storage, depending on the flavor selected. In this + case, the root file system can be on the persistent volume + and its state maintained even if the instance is shut down. + For more information about this type of configuration, see + the + OpenStack Configuration Reference. Persistent volumes do not provide concurrent access @@ -241,13 +244,13 @@
EC2 compatibility API - In addition to the native compute API, OpenStack provides an EC2-compatible API. This - API allows EC2 legacy workflows built for EC2 to work with OpenStack. The - - OpenStack Configuration Reference - lists configuration options - for customizing this compatibility API on your OpenStack cloud. + In addition to the native compute API, OpenStack provides + an EC2-compatible API. This API allows EC2 legacy workflows + built for EC2 to work with OpenStack. For more information and + configuration options about this compatibility API, see the + OpenStack Configuration Reference. + Numerous third-party tools and language-specific SDKs can be used to interact with OpenStack clouds, using both native and compatibility APIs. Some of the more popular @@ -392,13 +395,13 @@
Compute service architecture - The following basic categories describe the service architecture and what's going - on within the cloud controller. + These basic categories describe the service + architecture and information about the cloud controller. API server - At the heart of the cloud framework is an API server. This API server makes - command and control of the hypervisor, storage, and networking programmatically - available to users. + At the heart of the cloud framework is an API server, + which makes command and control of the hypervisor, storage, + and networking programmatically available to users. The API endpoints are basic HTTP web services which handle authentication, authorization, and basic command and control functions using various @@ -417,19 +420,23 @@ infrastructure), API endpoints, the scheduler (determines which physical hardware to allocate to a virtual resource), and similar components. - Communication to and from the cloud controller is + Communication to and from the cloud controller is handled by HTTP requests through multiple API endpoints. - A typical message passing event begins with the API server receiving a request - from a user. The API server authenticates the user and ensures that the user is - permitted to issue the subject command. The availability of objects implicated in - the request is evaluated and, if available, the request is routed to the queuing - engine for the relevant workers. Workers continually listen to the queue based on - their role, and occasionally their type host name. When an applicable work request - arrives on the queue, the worker takes assignment of the task and begins its - execution. Upon completion, a response is dispatched to the queue which is received - by the API server and relayed to the originating user. Database entries are queried, - added, or removed as necessary throughout the process. + A typical message passing event begins with the API + server receiving a request from a user. The API server + authenticates the user and ensures that they are permitted + to issue the subject command. The availability of objects + implicated in the request is evaluated and, if available, + the request is routed to the queuing engine for the + relevant workers. Workers continually listen to the queue + based on their role, and occasionally their type host name. + When an applicable work request arrives on the queue, the + worker takes assignment of the task and begins executing it. + Upon completion, a response is dispatched to the queue + which is received by the API server and relayed to the + originating user. Database entries are queried, added, or + removed as necessary during the process. Compute worker