trunk merge

4 files changed, 9 insertions, 8 deletions

diff --git a/doc/source/devref/index.rst b/doc/source/devref/index.rst
index 9613ba990..0a5a7a4d6 100644
--- a/doc/source/devref/index.rst
+++ b/doc/source/devref/index.rst
@@ -35,6 +35,7 @@ Programming Concepts
 .. toctree::
    :maxdepth: 3
 
+   zone
    rabbit
 
 API Reference
diff --git a/doc/source/devref/zone.rst b/doc/source/devref/zone.rst
index 3dd9d37d3..263560ee2 100644
--- a/doc/source/devref/zone.rst
+++ b/doc/source/devref/zone.rst
@@ -17,7 +17,7 @@
 Zones
 =====
 
-A Nova deployment is called a Zone. At the very least a Zone requires an API node, a Scheduler node, a database and RabbitMQ. Pushed further a Zone may contain many API nodes, many Scheduler, Volume, Network and Compute nodes as well as a cluster of databases and RabbitMQ servers. A Zone allows you to partition your deployments into logical groups for load balancing and instance distribution.
+A Nova deployment is called a Zone. A Zone allows you to partition your deployments into logical groups for load balancing and instance distribution. At the very least a Zone requires an API node, a Scheduler node, a database and RabbitMQ. Pushed further a Zone may contain many API nodes, many Scheduler, Volume, Network and Compute nodes as well as a cluster of databases and RabbitMQ servers. 
 
 The idea behind Zones is, if a particular deployment is not capable of servicing a particular request, the request may be forwarded to (child) Zones for possible processing. Zones may be nested in a tree fashion. 
 
@@ -34,7 +34,7 @@ Routing between Zones is based on the Capabilities of that Zone. Capabilities ar
 
   key=value;value;value, key=value;value;value
 
-Zones have Capabilities which are general to the Zone and are set via `--zone-capabilities` flag. Zones also have dynamic per-service Capabilities. Services derived from `nova.manager.SchedulerDependentManager` (such as Compute, Volume and Network) can set these capabilities by calling the `update_service_capabilities()` method on their `Manager` base class. These capabilities will be periodically sent to the Scheduler service automatically. The rate at which these updates are sent is controlled by the `--periodic_interval` flag.
+Zones have Capabilities which are general to the Zone and are set via `--zone_capabilities` flag. Zones also have dynamic per-service Capabilities. Services derived from `nova.manager.SchedulerDependentManager` (such as Compute, Volume and Network) can set these capabilities by calling the `update_service_capabilities()` method on their `Manager` base class. These capabilities will be periodically sent to the Scheduler service automatically. The rate at which these updates are sent is controlled by the `--periodic_interval` flag.
 
 Flow within a Zone
 ------------------
@@ -47,7 +47,7 @@ Inter-service communication within a Zone is done with RabbitMQ. Each class of S
 
 These capability messages are received by the Scheduler services and stored in the `ZoneManager` object. The SchedulerManager object has a reference to the `ZoneManager` it can use for load balancing.
 
-The `ZoneManager` also polls the child Zones periodically to gather their capabilities to aid in decision making. This is done via the OpenStack API `/v1.0/zones/info` REST call. This also captures the name of each child Zone. The Zone name is set via the `--zone-name` flag (and defaults to "nova"). 
+The `ZoneManager` also polls the child Zones periodically to gather their capabilities to aid in decision making. This is done via the OpenStack API `/v1.0/zones/info` REST call. This also captures the name of each child Zone. The Zone name is set via the `--zone_name` flag (and defaults to "nova"). 
 
 Zone administrative functions
 -----------------------------
diff --git a/doc/source/man/novamanage.rst b/doc/source/man/novamanage.rst
index 9c54f3608..397cc8e80 100644
--- a/doc/source/man/novamanage.rst
+++ b/doc/source/man/novamanage.rst
@@ -6,7 +6,7 @@ nova-manage
 control and manage cloud computer instances and images
 ------------------------------------------------------
 
-:Author: nova@lists.launchpad.net
+:Author: openstack@lists.launchpad.net
 :Date:   2010-11-16
 :Copyright: OpenStack LLC
 :Version: 0.1
@@ -121,7 +121,7 @@ Nova Role
 nova-manage role <action> [<argument>]
 ``nova-manage role add <username> <rolename> <(optional) projectname>``
 
-    Add a user to either a global or project-based role with the indicated <rolename> assigned to the named user. Role names can be one of the following five roles: admin, itsec, projectmanager, netadmin, developer. If you add the project name as the last argument then the role is assigned just for that project, otherwise the user is assigned the named role for all projects.
+    Add a user to either a global or project-based role with the indicated <rolename> assigned to the named user. Role names can be one of the following five roles: cloudadmin, itsec, sysadmin, netadmin, developer. If you add the project name as the last argument then the role is assigned just for that project, otherwise the user is assigned the named role for all projects.
 
 ``nova-manage role has <username> <projectname>``
     Checks the user or project and responds with True if the user has a global role with a particular project.
diff --git a/doc/source/runnova/managing.users.rst b/doc/source/runnova/managing.users.rst
index 392142e86..d3442bed9 100644
--- a/doc/source/runnova/managing.users.rst
+++ b/doc/source/runnova/managing.users.rst
@@ -38,11 +38,11 @@ Role-based access control (RBAC) is an approach to restricting system access to
 
 Nova’s rights management system employs the RBAC model and currently supports the following five roles:
 
-* **Cloud Administrator.**  (admin) Users of this class enjoy complete system access.
+* **Cloud Administrator.**  (cloudadmin) Users of this class enjoy complete system access.
 * **IT Security.** (itsec) This role is limited to IT security personnel.  It permits role holders to quarantine instances.
-* **Project Manager.** (projectmanager)The default for project owners, this role affords users the ability to add other users to a project, interact with project images, and launch and terminate instances.
+* **System Administrator.** (sysadmin) The default for project owners, this role affords users the ability to add other users to a project, interact with project images, and launch and terminate instances.
 * **Network Administrator.** (netadmin) Users with this role are permitted to allocate and assign publicly accessible IP addresses as well as create and modify firewall rules.
-* **Developer.**  This is a general purpose role that is assigned to users by default.
+* **Developer.**  (developer) This is a general purpose role that is assigned to users by default.
 
 RBAC management is exposed through the dashboard for simplified user management.