diff --git a/doc/openstack-ops/app_roadmaps.xml b/doc/openstack-ops/app_roadmaps.xml index 4612ab01..3f7f40d9 100644 --- a/doc/openstack-ops/app_roadmaps.xml +++ b/doc/openstack-ops/app_roadmaps.xml @@ -328,7 +328,7 @@ the Icehouse release and perhaps further afield. committee and technical leads of the projects.
- Aspects to watch + Aspects to Watch You want to keep an eye on these areas improving within OpenStack. The best ways to "watch" roadmaps for each project is to look at the blueprints that are being @@ -336,7 +336,7 @@ the Icehouse release and perhaps further afield. learn from PTL webinars that follow the OpenStack Summits twice a year.
- Driver quality improvements + Driver Quality Improvements A major quality push has occurred across drivers and plugins in Block Storage, Compute and Networking. Particularly, developers of Compute @@ -431,11 +431,12 @@ the Icehouse release and perhaps further afield.
Compute V3 API - The 3rd version of the Compute API will be released in - experimental status with Icehouse. Though the V2 API will - remain for two-to-three releases, this is the best time to - evaluate the new API and provide comments while it can be more - easily changed. Of particular note is the decision that the V3 + The 3rd version of the Compute API was broadly + discussed and worked on during the Havana and Icehouse + release cycles. Current discussions indicate that the V2 API will + remain for many releases, but this is a great time to + evaluate the Compute API and provide comments while it + is being defined. Of particular note is the decision that the V3 API will not support XML messages - being JSON only. This was based on the poor testing of existing XML responses in the V2 API, and lack of effort to continue to develop and maintain an @@ -447,17 +448,17 @@ the Icehouse release and perhaps further afield. Continues to improve and you may consider using it for greenfield deployments.
-
- Hadoop-as-a-Service (Savana) +
+ Hadoop-as-a-Service (Savanna for now with a rename coming) A much-requested answer to Big Data problems, a dedicated team has been making solid progress on a Hadoop-as-a-Service project.
- Bare-metal deployment (Ironic) + Bare-metal Deployment (Ironic) Though Bare-metal deployment has been widely lauded, and - development continues, the project to replace Compute's bare-metal - driver will likely not graduate in Icehouse. A particular blueprint to + development continues, the project to replace the Compute bare-metal + driver will not graduate in Icehouse. A particular blueprint to follow is Migration path from Nova's BM driver, which tracks the ability to move to the new project from an existing bare metal deployment. @@ -475,7 +476,7 @@ the Icehouse release and perhaps further afield.
Messaging as a Service (Marconi) A service to provide queues of messages and notifications - has entered 'incubation', meaning if the next two + has entered 'incubation', meaning if the upcoming development cycles are successful, it will be released in Juno.
@@ -496,7 +497,7 @@ the Icehouse release and perhaps further afield. control for volumes.
- Toward a 'proper' Python SDK + Toward a 'Proper' Python SDK Though many successfully use the various python-*client code as an effective SDK for interacting with OpenStack, consistency between the projects and documentation availability waxes and wanes. To combat diff --git a/doc/openstack-ops/ch_arch_cloud_controller.xml b/doc/openstack-ops/ch_arch_cloud_controller.xml index 8f416550..cf5d2968 100644 --- a/doc/openstack-ops/ch_arch_cloud_controller.xml +++ b/doc/openstack-ops/ch_arch_cloud_controller.xml @@ -295,7 +295,7 @@
Message Queue Most OpenStack services communicate with each other using the - Message Queue. As an example, Compute communicates to block storage + Message Queue. For example, Compute communicates to block storage services and networking services through the message queue. Also, you can optionally enable notifications for any service. RabbitMQ, Qpid, and 0mq are all popular choices for a message queue service. @@ -434,18 +434,18 @@ supports: - OpenStack Object Storage. Allows you to store + OpenStack Object Storage: Allows you to store images as objects. - File system. Uses any traditional file system to + File system: Uses any traditional file system to store the images as files. - S3. Allows you to fetch images from Amazon S3. + S3: Allows you to fetch images from Amazon S3. - HTTP. Allows you to fetch images from a web + HTTP: Allows you to fetch images from a web server. You cannot write images by using this mode. diff --git a/doc/openstack-ops/ch_arch_compute_nodes.xml b/doc/openstack-ops/ch_arch_compute_nodes.xml index 53231297..54ba5981 100644 --- a/doc/openstack-ops/ch_arch_compute_nodes.xml +++ b/doc/openstack-ops/ch_arch_compute_nodes.xml @@ -18,7 +18,7 @@ Compute cloud, providing the processing, memory, network and storage resources to run instances.
- CPU Choice + Choosing a CPU The type of CPU in your compute node is a very important choice. First, ensure the CPU supports virtualization by way of VT-x for Intel chips and @@ -54,7 +54,7 @@
- Hypervisor Choice + Choosing a Hypervisor A hypervisor provides software to manage virtual machine access to the underlying hardware. The hypervisor creates, manages, and monitors virtual machines. OpenStack Compute supports many @@ -96,7 +96,6 @@ single hypervisor at a time.
-
Instance Storage Solutions As part of the procurement for a compute cluster, you @@ -223,7 +222,6 @@
-
On Compute Node Storage – Non-shared File System In this option, each compute node is specified with enough diff --git a/doc/openstack-ops/ch_arch_examples.xml b/doc/openstack-ops/ch_arch_examples.xml index 40e3d8ed..a9ed5ff5 100644 --- a/doc/openstack-ops/ch_arch_examples.xml +++ b/doc/openstack-ops/ch_arch_examples.xml @@ -26,8 +26,8 @@ documenting, as well as to provide the scope for this guide. Both of the offered architecture examples are currently running in production and serving users. - As always, refer to the Glossary if you are unclear about any of the - terminology mentioned in these architectures. + As always, refer to the Glossary if you are unclear about any of the + terminology mentioned in these architectures.
diff --git a/doc/openstack-ops/ch_arch_scaling.xml b/doc/openstack-ops/ch_arch_scaling.xml index 8f231407..344a501e 100644 --- a/doc/openstack-ops/ch_arch_scaling.xml +++ b/doc/openstack-ops/ch_arch_scaling.xml @@ -197,7 +197,10 @@
Segregating Your Cloud - Use one of the following OpenStack methods to segregate + When you want to offer users different regions to provide legal + considerations for data storage, redundancy across earthquake fault + lines, or for low-latency API calls, you segregate your cloud. + Use one of the following OpenStack methods to segregate your cloud: cells, regions, zones and host @@ -431,26 +434,26 @@ each resources. It is left up to you to avoid putting a host in multiple aggregates that define different values for the same resource. - This is the first half of the equation. To get - instance types that are guaranteed a particular ratio - you must set the extra_specs in - the instance type to the key value pair you want to - match in the aggregate. For example if you define extra - specs cpu_allocation_ratio to - '1.0' then instances of that type will only run in - aggregates where the metadata key - cpu_allocation_ratio is also - defined as '1.0'. In practice it is better to define an - additional key value pair in the aggregate metadata to - match on rather than match directly on - cpu_allocation_ratio or - core_allocation_ratio. This - allows better abstraction. For example, defining a key - overcommit and setting value - of 'high', 'medium', and 'low' you could then tune the - numeric allocation ratios in the aggregates without also - needing to change all instance types relating to - them. + This is the first half of the equation. To + get instance types that are guaranteed a + particular ratio you must set the extra_specs + in the instance type to the key value pair you want to match in the aggregate. + For example if you define extra specs + cpu_allocation_ratio to + '1.0' then instances of that type will only + run in aggregates where the metadata key + cpu_allocation_ratio + is also defined as '1.0'. In practice it is + better to define an additional key value pair + in the aggregate metadata to match on rather + than match directly on cpu_allocation_ratio + or core_allocation_ratio. + This allows better abstraction. For example by + defining a key overcommit + and setting value of 'high', 'medium', or 'low' + you could then tune the numeric allocation + ratios in the aggregates without also needing + to change all instance types relating to them. Previously, all services had an availability zone. Currently, diff --git a/doc/openstack-ops/ch_ops_network_troubleshooting.xml b/doc/openstack-ops/ch_ops_network_troubleshooting.xml index c76bf7ee..63981716 100644 --- a/doc/openstack-ops/ch_ops_network_troubleshooting.xml +++ b/doc/openstack-ops/ch_ops_network_troubleshooting.xml @@ -832,7 +832,7 @@ bytes 174.143.194.225 (47)
- Trouble shooting Open vSwitch + Troubleshooting Open vSwitch Open vSwitch as used in the OpenStack Networking Service examples above is full-featured multilayer virtual switch licensed under the open source Apache 2.0 license. Full documentation can be found at diff --git a/doc/openstack-ops/ch_ops_projects_users.xml b/doc/openstack-ops/ch_ops_projects_users.xml index 9f0582dc..be2db217 100644 --- a/doc/openstack-ops/ch_ops_projects_users.xml +++ b/doc/openstack-ops/ch_ops_projects_users.xml @@ -157,7 +157,7 @@ - Fixed Ips + Fixed IPs Number of fixed IP addresses allowed per tenant. This number diff --git a/doc/openstack-ops/ch_ops_user_facing.xml b/doc/openstack-ops/ch_ops_user_facing.xml index 5410079b..9bc092c6 100644 --- a/doc/openstack-ops/ch_ops_user_facing.xml +++ b/doc/openstack-ops/ch_ops_user_facing.xml @@ -601,7 +601,7 @@ Optional snapshot description. (Default=None) | tenant_id | 98333a1a28e746fa8c629c83a818ad57 / | updated | 2013-03-01T19:28:26Z \ | user_id | a1ef823458d24a68955fec6f3d390019 / -+------------------------+-----------------------------------------------------\ ++------------------------+----------------------------------------------------\ In this case looking at the "fault" message shows NoValidHost indicating the scheduler was unable to diff --git a/doc/openstack-ops/part_architecture.xml b/doc/openstack-ops/part_architecture.xml index e00c0c37..2e4008ac 100644 --- a/doc/openstack-ops/part_architecture.xml +++ b/doc/openstack-ops/part_architecture.xml @@ -20,6 +20,32 @@ needs, and this part of the book aims to shine light on many of the decisions you will need to make during the process. + To design, deploy, and configure OpenStack, administrators + must understand the logical architecture. A diagram can help + you envision all the integrated services within + OpenStack and how they interact with each other. + 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. + + + Command-line interface (CLI). Enables users to submit API + calls to OpenStack services through commands. + + + As shown, 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. The diagram shows the + most common, but not the only, logical architecture for an + OpenStack cloud. + diff --git a/doc/openstack-ops/preface_ops.xml b/doc/openstack-ops/preface_ops.xml index 43be8545..5fb215d7 100644 --- a/doc/openstack-ops/preface_ops.xml +++ b/doc/openstack-ops/preface_ops.xml @@ -18,7 +18,7 @@
Introduction to OpenStack OpenStack believes in open source, open design, open development, all in an open - community encouraging participation by anyone. The long-term vision for OpenStack + community which encourages participation by anyone. The long-term vision for OpenStack is to produce a ubiquitous open source cloud computing platform that meets the needs of public and private cloud providers regardless of size. OpenStack services control large pools of compute, storage, and networking resources throughout a data center. @@ -34,7 +34,7 @@ computing platform for both public and private clouds. By focusing on ease of implementation, massive scalability, a variety of rich features and tremendous extensibility, the project aims to deliver a practical and reliable cloud solution for - all types of organisations. + all types of organisations.
Getting Started with OpenStack As an open source project, one of the unique aspects about OpenStack is that there are many different levels you can begin to engage with it — you don't have to do everything @@ -94,7 +94,6 @@ number of options might be bewildering at first.
-
Who This Book Is For This book is for those of you starting to run OpenStack clouds as @@ -429,7 +428,6 @@
-
How to Contribute to This Book The genesis of this book was an in-person event, but now that the @@ -457,5 +455,4 @@ if you know how to fix it. Also, a member of the OpenStack doc-core team can triage the doc bug.
-