Normalization of Dev reference docs.

16 files changed, 225 insertions, 153 deletions

diff --git a/doc/source/devref/api.rst b/doc/source/devref/api.rst
index cad0e820a..e9b79d8dd 100644
--- a/doc/source/devref/api.rst
+++ b/doc/source/devref/api.rst
@@ -15,8 +15,8 @@
       License for the specific language governing permissions and limitations
       under the License.
 
-API Endpoint Programming Guide
-==============================
+API Endpoint
+============
 
 Nova has a system for managing multiple APIs on different subdomains.
 Currently there is support for the OpenStack API, as well as the Amazon EC2
@@ -33,7 +33,7 @@ The :mod:`nova.api` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`cloud` Module
+The :mod:`nova.api.cloud` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.api.cloud
diff --git a/doc/source/devref/auth.rst b/doc/source/devref/auth.rst
index 77d97f68b..ee82df5ab 100644
--- a/doc/source/devref/auth.rst
+++ b/doc/source/devref/auth.rst
@@ -17,10 +17,10 @@
 
 .. _auth:
 
-Authentication and Authorization Programming Guide
-==================================================
+Authentication and Authorization
+================================
 
-The :mod:`quota` Module
+The :mod:`nova.quota` Module
 -----------------------
 
 .. automodule:: nova.quota
@@ -28,10 +28,20 @@ The :mod:`quota` Module
     :undoc-members:
     :show-inheritance:
 
+
+The :mod:`nova.auth.signer` Module
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. automodule:: nova.auth.signer
+    :members:
+    :undoc-members:
+    :show-inheritance:
+
+
 Auth Manager
 ------------
 
-The :mod:`manager` Module
+The :mod:`nova.auth.manager` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.auth.manager
@@ -39,10 +49,8 @@ The :mod:`manager` Module
     :undoc-members:
     :show-inheritance:
 
-Drivers
--------
 
-The :mod:`ldapdriver` Module
+The :mod:`nova.auth.ldapdriver` Driver
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.auth.ldapdriver
@@ -50,7 +58,7 @@ The :mod:`ldapdriver` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`dbdriver` Module
+The :mod:`nova.auth.dbdriver` Driver
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.auth.dbdriver
@@ -58,19 +66,10 @@ The :mod:`dbdriver` Module
     :undoc-members:
     :show-inheritance:
 
-API Integration
----------------
 
-The :mod:`signer` Module
-~~~~~~~~~~~~~~~~~~~~~~~~
+Tests
+-----
 
-.. automodule:: nova.auth.signer
-    :members:
-    :undoc-members:
-    :show-inheritance:
-
-Related Tests
--------------
 
 The :mod:`auth_unittest` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -80,6 +79,7 @@ The :mod:`auth_unittest` Module
     :undoc-members:
     :show-inheritance:
 
+
 The :mod:`access_unittest` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -88,6 +88,7 @@ The :mod:`access_unittest` Module
     :undoc-members:
     :show-inheritance:
 
+
 The :mod:`quota_unittest` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -96,7 +97,8 @@ The :mod:`quota_unittest` Module
     :undoc-members:
     :show-inheritance:
 
-legacy docs
+
+Legacy Docs
 -----------
 
 Nova provides RBAC (Role-based access control) of the AWS-type APIs. We define the following roles:
@@ -104,12 +106,14 @@ Nova provides RBAC (Role-based access control) of the AWS-type APIs. We define t
 Roles-Based Access Control of AWS-style APIs using SAML Assertions
 “Achieving FIPS 199 Moderate certification of a hybrid cloud environment using CloudAudit and declarative C.I.A. classifications”
 
+
 Introduction
 ------------
 
 We will investigate one method for integrating an AWS-style API with US eAuthentication-compatible federated authentication systems, to achieve access controls and limits based on traditional operational roles.
 Additionally, we will look at how combining this approach, with an implementation of the CloudAudit APIs, will allow us to achieve a certification under FIPS 199 Moderate classification for a hybrid cloud environment.
 
+
 Relationship of US eAuth to RBAC
 --------------------------------
 
@@ -125,6 +129,7 @@ In more ideal implementations, the remainder of the application-specific account
 
 .. _auth_roles:
 
+
 Roles
 -----
 
@@ -172,6 +177,7 @@ Cloud Administrator/IT-Security:
 
 *	All permissions
 
+
 Enhancements
 ------------
 
@@ -182,6 +188,7 @@ Enhancements
 Wrapping the SAML token into the API calls.
 Then store the UID (fetched via backchannel) into the instance metadata, providing end-to-end auditability of ownership and responsibility, without PII.
 
+
 CloudAudit APIs
 ---------------
 
@@ -192,6 +199,7 @@ CloudAudit APIs
 CloudAudit queries may spawn long-running processes (similar to launching instances, etc.) They need to return a ReservationId in the same fashion, which can be returned in further queries for updates.
 RBAC of CloudAudit API calls is critical, since detailed system information is a system vulnerability.
 
+
 Type declarations
 -----------------
 *	Data declarations – Volumes and Objects
@@ -203,17 +211,19 @@ Existing API calls to launch instances specific a single, combined “type” fl
 
 These additional parameters would also apply to creation of block storage volumes (along with the existing parameter of ‘size’), and creation of object storage ‘buckets’. (C.I.A. classifications on a bucket would be inherited by the keys within this bucket.)
 
+
 Request Brokering
 -----------------
 
- *	Cloud Interop
- *	IMF Registration / PubSub
- *	Digital C&A
+*	Cloud Interop
+*	IMF Registration / PubSub
+*	Digital C&A
 
 Establishing declarative semantics for individual API calls will allow the cloud environment to seamlessly proxy these API calls to external, third-party vendors – when the requested CIA levels match.
 
 See related work within the Infrastructure 2.0 working group for more information on how the IMF Metadata specification could be utilized to manage registration of these vendors and their C&A credentials.
 
+
 Dirty Cloud – Hybrid Data Centers
 ---------------------------------
 
@@ -226,12 +236,14 @@ This interconnect is typically a bridged VPN connection. Any machines that can b
 
 Network discovery protocols (ARP, CDP) can be applied in this case, and existing protocols (SNMP location data, DNS LOC records) overloaded to provide CloudAudit information.
 
+
 The Details
 -----------
 
- *	Preliminary Roles Definitions
- *	Categorization of available API calls
- *	SAML assertion vocabulary
+*	Preliminary Roles Definitions
+*	Categorization of available API calls
+*	SAML assertion vocabulary
+
 
 System limits
 -------------
@@ -249,10 +261,8 @@ The following limits need to be defined and enforced:
 
 Further Challenges
 ------------------
- *	Prioritization of users / jobs in shared computing environments
- *	Incident response planning
- *	Limit launch of instances to specific security groups based on AMI
- *	Store AMIs in LDAP for added property control
-
-
 
+*	Prioritization of users / jobs in shared computing environments
+*	Incident response planning
+*	Limit launch of instances to specific security groups based on AMI
+*	Store AMIs in LDAP for added property control
diff --git a/doc/source/devref/cloudpipe.rst b/doc/source/devref/cloudpipe.rst
index 5264a0f39..d6d456a6b 100644
--- a/doc/source/devref/cloudpipe.rst
+++ b/doc/source/devref/cloudpipe.rst
@@ -23,11 +23,13 @@ Cloudpipe -- Per Project Vpns
 
 Cloudpipe is a method for connecting end users to their project insnances in vlan mode.
 
+
 Overview
 --------
 
 The support code for cloudpipe implements admin commands (via nova-manage) to automatically create a vm for a project that allows users to vpn into the private network of their project. Access to this vpn is provided through a public port on the network host for the project.  This allows users to have free access to the virtual machines in their project without exposing those machines to the public internet.
 
+
 Cloudpipe Image
 ---------------
 
@@ -35,6 +37,7 @@ The cloudpipe image is basically just a linux instance with openvpn installed.
 
 It is also useful to have a cron script that will periodically redownload the metadata and copy the new crl.  This will keep revoked users from connecting and will disconnect any users that are connected with revoked certificates when their connection is renegotiated (every hour).
 
+
 Cloudpipe Launch
 ----------------
 
@@ -46,6 +49,7 @@ When you use nova-manage to launch a cloudpipe for a user, it goes through the f
 #. zips up the info and puts it b64 encoded as user data
 #. launches an m1.tiny instance with the above settings using the flag-specified vpn image
 
+
 Vpn Access
 ----------
 
@@ -59,7 +63,8 @@ Certificates and Revocation
 
 If the use_project_ca flag is set (required to for cloudpipes to work securely), then each project has its own ca.  This ca is used to sign the certificate for the vpn, and is also passed to the user for bundling images.  When a certificate is revoked using nova-manage, a new Certificate Revocation List (crl) is generated.  As long as cloudpipe has an updated crl, it will block revoked users from connecting to the vpn.
 
-The :mod:`cloudpipe` Module
+
+The :mod:`nova.cloudpipe.pipelib` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.cloudpipe.pipelib
@@ -67,7 +72,8 @@ The :mod:`cloudpipe` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`api.cloudpipe` Module
+
+The :mod:`nova.api.cloudpipe` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.api.cloudpipe
@@ -75,7 +81,8 @@ The :mod:`api.cloudpipe` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`crypto` Module
+
+The :mod:`nova.crypto` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.crypto
diff --git a/doc/source/devref/compute.rst b/doc/source/devref/compute.rst
index e4c6c6ae7..741ea6041 100644
--- a/doc/source/devref/compute.rst
+++ b/doc/source/devref/compute.rst
@@ -16,19 +16,18 @@
       under the License.
 
 
-Virtualization Programming Guide
-================================
+Virtualization
+==============
 
-This page contains the Compute Package documentation.
 
-Manager
+Compute
 -------
 
 Documentation for the compute manager and related files.  For reading about
 a specific virtualization backend, read Drivers_.
 
 
-The :mod:`manager` Module
+The :mod:`nova.compute.manager` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.compute.manager
@@ -36,7 +35,7 @@ The :mod:`manager` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`connection` Module
+The :mod:`nova.virt.connection` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.virt.connection
@@ -44,7 +43,7 @@ The :mod:`connection` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`disk` Module
+The :mod:`nova.compute.disk` Module
 ~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.compute.disk
@@ -52,7 +51,7 @@ The :mod:`disk` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`images` Module
+The :mod:`nova.virt.images` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.virt.images
@@ -61,7 +60,7 @@ The :mod:`images` Module
     :show-inheritance:
 
 
-The :mod:`instance_types` Module
+The :mod:`nova.compute.instance_types` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.compute.instance_types
@@ -70,7 +69,7 @@ The :mod:`instance_types` Module
     :show-inheritance:
 
 
-The :mod:`power_state` Module
+The :mod:`nova.compute.power_state` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.compute.power_state
@@ -82,42 +81,38 @@ The :mod:`power_state` Module
 Drivers
 -------
 
-Libvirt Implementations
-~~~~~~~~~~~~~~~~~~~~~~~
 
-The libvirt driver is capable of supporting KVM, QEMU, and UML.
-
-The :mod:`libvirt_conn` Module
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+The :mod:`nova.virt.libvirt_conn` Driver
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.virt.libvirt_conn
     :members:
     :undoc-members:
     :show-inheritance:
 
-XEN
-~~~
 
-The :mod:`xenapi` Module
-^^^^^^^^^^^^^^^^^^^^^^^^
+The :mod:`nova.virt.xenapi` Driver
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.virt.xenapi
     :members:
     :undoc-members:
     :show-inheritance:
 
-FAKE
-~~~~
+
+The :mod:`nova.virt.fake` Driver
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.virt.fake
     :members:
     :undoc-members:
     :show-inheritance:
 
+
 Monitoring
 ----------
 
-The :mod:`monitor` Module
+The :mod:`nova.compute.monitor` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.compute.monitor
diff --git a/doc/source/devref/database.rst b/doc/source/devref/database.rst
index b58ea147d..1b41990ab 100644
--- a/doc/source/devref/database.rst
+++ b/doc/source/devref/database.rst
@@ -15,10 +15,10 @@
       License for the specific language governing permissions and limitations
       under the License.
 
-Database Programming Guide
-==========================
+The Database Layer
+==================
 
-The :mod:`api` Module
+The :mod:`nova.db.api` Module
 ---------------------
 
 .. automodule:: nova.db.api
@@ -27,33 +27,31 @@ The :mod:`api` Module
     :show-inheritance:
 
 
-Drivers
--------
-
-Driver: Sqlalchemy
-~~~~~~~~~~~~~~~~~~
+The Sqlalchemy Driver
+---------------------
 
-The :mod:`sqlalchemy.api` Module
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+The :mod:`nova.db.sqlalchemy.api` Module
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.db.sqlalchemy.api
 
-The :mod:`sqlalchemy.models` Module
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+The :mod:`nova.db.sqlalchemy.models` Module
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.db.sqlalchemy.models
     :members:
     :undoc-members:
     :show-inheritance:
 
-The :mod:`sqlalchemy.session` Module
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+The :mod:`nova.db.sqlalchemy.session` Module
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.db.sqlalchemy.session
     :members:
     :undoc-members:
     :show-inheritance:
 
+
 Tests
 -----
 
diff --git a/doc/source/devref/fakes.rst b/doc/source/devref/fakes.rst
index 61622754c..adba57969 100644
--- a/doc/source/devref/fakes.rst
+++ b/doc/source/devref/fakes.rst
@@ -15,13 +15,16 @@
       License for the specific language governing permissions and limitations
       under the License.
 
-Fakes Programming Guide
-=======================
+Fake Drivers
+============
 
 .. todo:: document general info about fakes
 
+When the real thing isn't available and you have some development to do these
+fake implementations of various drivers let you get on with your day.
 
-The :mod:`virt.fake` Module
+
+The :mod:`nova.virt.fake` Module
 ---------------------------
 
 .. automodule:: nova.virt.fake
@@ -29,8 +32,9 @@ The :mod:`virt.fake` Module
     :undoc-members:
     :show-inheritance:
     :noindex:
-    
-The :mod:`fakeldap` Module
+
+
+The :mod:`nova.auth.fakeldap` Module
 --------------------------
 
 .. automodule:: nova.auth.fakeldap
@@ -38,7 +42,8 @@ The :mod:`fakeldap` Module
     :undoc-members:
     :show-inheritance:
     
-The :mod:`fakerabbit` Module
+
+The :mod:`nova.fakerabbit` Module
 ----------------------------
 
 .. automodule:: nova.fakerabbit
@@ -46,7 +51,8 @@ The :mod:`fakerabbit` Module
     :undoc-members:
     :show-inheritance:
 
-The :class:`FakeAOEDriver` Class
+
+The :class:`nova.volume.driver.FakeAOEDriver` Class
 --------------------------------
 
 .. autoclass:: nova.volume.driver.FakeAOEDriver
@@ -54,7 +60,8 @@ The :class:`FakeAOEDriver` Class
     :undoc-members:
     :show-inheritance:
 
-The :class:`service_unittest.FakeManager` Class
+
+The :class:`nova.tests.service_unittest.FakeManager` Class
 -----------------------------------------------
 
 .. autoclass:: nova.tests.service_unittest.FakeManager
@@ -62,7 +69,8 @@ The :class:`service_unittest.FakeManager` Class
     :undoc-members:
     :show-inheritance:
 
-The :mod:`api.openstack.fakes` Module
+
+The :mod:`nova.tests.api.openstack.fakes` Module
 ------------------------------------------------
 
 .. automodule:: nova.tests.api.openstack.fakes
diff --git a/doc/source/devref/glance.rst b/doc/source/devref/glance.rst
index 3d0f4ebec..8a9dd7d80 100644
--- a/doc/source/devref/glance.rst
+++ b/doc/source/devref/glance.rst
@@ -15,10 +15,10 @@
       License for the specific language governing permissions and limitations
       under the License.
 
-Glance Integration Programming Guide
-====================================
+Glance Integration - The Future of File Storage
+===============================================
 
-The :mod:`image.service` Module
+The :mod:`nova.image.service` Module
 -------------------------------
 
 .. automodule:: nova.image.service
diff --git a/doc/source/devref/index.rst b/doc/source/devref/index.rst
index a14460405..39d4c560e 100644
--- a/doc/source/devref/index.rst
+++ b/doc/source/devref/index.rst
@@ -18,10 +18,11 @@
 Nova Development Reference
 ==========================
 
-Nova is written in python.
+Nova is written in Python.
 
 Prerequisites
 -------------
+
 .. toctree::
    :maxdepth: 1
 
diff --git a/doc/source/devref/network.rst b/doc/source/devref/network.rst
index 318286383..9b70b7830 100644
--- a/doc/source/devref/network.rst
+++ b/doc/source/devref/network.rst
@@ -15,24 +15,25 @@
       License for the specific language governing permissions and limitations
       under the License.
 
-Networking Programming Guide
-============================
+Networking
+==========
 
 .. todo:: 
 
     * document hardware specific commands (maybe in admin guide?) (todd)
     * document a map between flags and managers/backends (todd)
 
-The :mod:`Manager` module
--------------------------
+
+The :mod:`nova.network.manager` Module
+--------------------------------------
 
 .. automodule:: nova.network.manager
     :members:
     :undoc-members:
     :show-inheritance:
 
-The :mod:`LinuxNet` driver
---------------------------
+The :mod:`nova.network.linux_net` Driver
+----------------------------------------
 
 .. automodule:: nova.network.linux_net
     :members:
@@ -51,7 +52,7 @@ The :mod:`network_unittest` Module
     :show-inheritance:
 
 
-legacy docs
+Legacy docs
 -----------
 
 The nova networking components manage private networks, public IP addressing, VPN connectivity, and firewall rules.
diff --git a/doc/source/devref/nova.rst b/doc/source/devref/nova.rst
index 58125dc80..ff2b6ce9f 100644
--- a/doc/source/devref/nova.rst
+++ b/doc/source/devref/nova.rst
@@ -15,10 +15,14 @@
       License for the specific language governing permissions and limitations
       under the License.
 
-Nova Libraries Programming Guide
-================================
+Common and Misc Libraries
+=========================
 
-The :mod:`adminclient` Module
+Libraries common throughout Nova or just ones that haven't been categorized
+very well yet.
+
+
+The :mod:`nova.adminclient` Module
 -----------------------------
 
 .. automodule:: nova.adminclient
@@ -26,7 +30,8 @@ The :mod:`adminclient` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`context` Module
+
+The :mod:`nova.context` Module
 -------------------------
 
 .. automodule:: nova.context
@@ -34,7 +39,8 @@ The :mod:`context` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`exception` Module
+
+The :mod:`nova.exception` Module
 ---------------------------
 
 .. automodule:: nova.exception
@@ -42,7 +48,8 @@ The :mod:`exception` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`flags` Module
+
+The :mod:`nova.flags` Module
 -----------------------
 
 .. automodule:: nova.flags
@@ -50,7 +57,8 @@ The :mod:`flags` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`process` Module
+
+The :mod:`nova.process` Module
 -------------------------
 
 .. automodule:: nova.process
@@ -58,7 +66,8 @@ The :mod:`process` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`rpc` Module
+
+The :mod:`nova.rpc` Module
 ---------------------
 
 .. automodule:: nova.rpc
@@ -66,7 +75,8 @@ The :mod:`rpc` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`server` Module
+
+The :mod:`nova.server` Module
 ------------------------
 
 .. automodule:: nova.server
@@ -74,7 +84,8 @@ The :mod:`server` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`test` Module
+
+The :mod:`nova.test` Module
 ----------------------
 
 .. automodule:: nova.test
@@ -82,7 +93,8 @@ The :mod:`test` Module
     :undoc-members:
     :show-inheritance:  
 
-The :mod:`twistd` Module
+
+The :mod:`nova.twistd` Module
 ------------------------
 
 .. automodule:: nova.twistd
@@ -90,7 +102,8 @@ The :mod:`twistd` Module
     :undoc-members:
     :show-inheritance:  
 
-The :mod:`utils` Module
+
+The :mod:`nova.utils` Module
 -----------------------
 
 .. automodule:: nova.utils
@@ -98,7 +111,8 @@ The :mod:`utils` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`validate` Module
+
+The :mod:`nova.validate` Module
 --------------------------
 
 .. automodule:: nova.validate
@@ -106,7 +120,8 @@ The :mod:`validate` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`wsgi` Module
+
+The :mod:`nova.wsgi` Module
 ----------------------
 
 .. automodule:: nova.wsgi
@@ -114,6 +129,7 @@ The :mod:`wsgi` Module
     :undoc-members:
     :show-inheritance:
 
+
 Tests
 -----
 
@@ -125,6 +141,7 @@ The :mod:`declare_flags` Module
     :undoc-members:
     :show-inheritance:
 
+
 The :mod:`fake_flags` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -133,6 +150,7 @@ The :mod:`fake_flags` Module
     :undoc-members:
     :show-inheritance:
 
+
 The :mod:`flags_unittest` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -141,6 +159,7 @@ The :mod:`flags_unittest` Module
     :undoc-members:
     :show-inheritance:
 
+
 The :mod:`process_unittest` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -149,6 +168,7 @@ The :mod:`process_unittest` Module
     :undoc-members:
     :show-inheritance:
 
+
 The :mod:`real_flags` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -157,6 +177,7 @@ The :mod:`real_flags` Module
     :undoc-members:
     :show-inheritance:
 
+
 The :mod:`rpc_unittest` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -165,6 +186,7 @@ The :mod:`rpc_unittest` Module
     :undoc-members:
     :show-inheritance:
 
+
 The :mod:`runtime_flags` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -173,6 +195,7 @@ The :mod:`runtime_flags` Module
     :undoc-members:
     :show-inheritance:
 
+
 The :mod:`twistd_unittest` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -181,6 +204,7 @@ The :mod:`twistd_unittest` Module
     :undoc-members:
     :show-inheritance:
 
+
 The :mod:`validator_unittest` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
diff --git a/doc/source/devref/objectstore.rst b/doc/source/devref/objectstore.rst
index 4087b5dd0..473f32026 100644
--- a/doc/source/devref/objectstore.rst
+++ b/doc/source/devref/objectstore.rst
@@ -15,10 +15,10 @@
       License for the specific language governing permissions and limitations
       under the License.
 
-Objectstore Programming Guide
-=============================
+Objectstore - File Storage Service
+==================================
 
-The :mod:`handler` Module
+The :mod:`nova.objectstore.handler` Module
 -------------------------
 
 .. automodule:: nova.objectstore.handler
@@ -26,7 +26,8 @@ The :mod:`handler` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`bucket` Module
+
+The :mod:`nova.objectstore.bucket` Module
 ------------------------
 
 .. automodule:: nova.objectstore.bucket
@@ -34,7 +35,8 @@ The :mod:`bucket` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`stored` Module
+
+The :mod:`nova.objectstore.stored` Module
 ------------------------
 
 .. automodule:: nova.objectstore.stored
@@ -42,7 +44,8 @@ The :mod:`stored` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`image` Module
+
+The :mod:`nova.objecstore.image` Module
 -----------------------
 
 .. automodule:: nova.objectstore.image
@@ -50,6 +53,7 @@ The :mod:`image` Module
     :undoc-members:
     :show-inheritance:
 
+
 Tests
 -----
 
diff --git a/doc/source/devref/scheduler.rst b/doc/source/devref/scheduler.rst
index df820c2f2..d3a6132e5 100644
--- a/doc/source/devref/scheduler.rst
+++ b/doc/source/devref/scheduler.rst
@@ -15,10 +15,10 @@
       License for the specific language governing permissions and limitations
       under the License.
 
-Scheduler Programming Guide
-===========================
+Scheduler
+=========
 
-The :mod:`manager` Module
+The :mod:`nova.scheduler.manager` Module
 -------------------------
 
 .. automodule:: nova.scheduler.manager
@@ -26,7 +26,8 @@ The :mod:`manager` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`driver` Module
+
+The :mod:`nova.scheduler.driver` Module
 ------------------------
 
 .. automodule:: nova.scheduler.driver
@@ -34,7 +35,8 @@ The :mod:`driver` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`chance` Module
+
+The :mod:`nova.scheduler.chance` Driver
 ------------------------
 
 .. automodule:: nova.scheduler.chance
@@ -42,7 +44,8 @@ The :mod:`chance` Module
     :undoc-members:
     :show-inheritance:
 
-The :mod:`simple` Module
+
+The :mod:`nova.scheduler.simple` Driver
 ------------------------
 
 .. automodule:: nova.scheduler.simple
@@ -50,6 +53,7 @@ The :mod:`simple` Module
     :undoc-members:
     :show-inheritance:
 
+
 Tests
 -----
 
diff --git a/doc/source/devref/services.rst b/doc/source/devref/services.rst
index 517a51901..fe84e20d8 100644
--- a/doc/source/devref/services.rst
+++ b/doc/source/devref/services.rst
@@ -17,53 +17,34 @@
 
 .. _service_manager_driver:
 
-Services Managers and Drivers
-=============================
+Services, Managers and Drivers
+==============================
 
 The responsibilities of Services, Managers, and Drivers, can be a bit confusing to people that are new to nova.  This document attempts to outline the division of responsibilities to make understanding the system a little bit easier.
 
 Currently, Managers and Drivers are specified by flags and loaded using utils.load_object().  This method allows for them to be implemented as singletons, classes, modules or objects.  As long as the path specified by the flag leads to an object (or a callable that returns an object) that responds to getattr, it should work as a manager or driver.
 
-Service
--------
 
-A service is a very thin wrapper around a Manager object.  It exposes the manager's public methods to other components of the system via rpc.  It will report state periodically to the database and is responsible for initiating any periodic tasts that need to be executed on a given host.
-
-The :mod:`service` Module
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The :mod:`nova.service` Module
+------------------------------
 
 .. automodule:: nova.service
     :members:
     :undoc-members:
     :show-inheritance:
 
-Manager
--------
-
-Managers are responsible for a certain aspect of the sytem.  It is a logical grouping of code relating to a portion of the system.  In general other components should be using the manager to make changes to the components that it is responsible for.
-
-For example, other components that need to deal with volumes in some way, should do so by calling methods on the VolumeManager instead of directly changing fields in the database.  This allows us to keep all of the code relating to volumes in the same place.
-
-We have adopted a basic strategy of Smart managers and dumb data, which means rather than attaching methods to data objects, components should call manager methods that act on the data.
-
-Methods on managers that can be executed locally should be called directly. If a particular method must execute on a remote host, this should be done via rpc to the service that wraps the manager
 
-Managers should be responsible for most of the db access, and non-implementation specific data.  Anything implementation specific that can't be generalized should be done by the Driver.
-
-In general, we prefer to have one manager with multiple drivers for different implementations, but sometimes it makes sense to have multiple managers.  You can think of it this way: Abstract different overall strategies at the manager level(FlatNetwork vs VlanNetwork), and different implementations at the driver level(LinuxNetDriver vs CiscoNetDriver).
-
-Managers will often provide methods for initial setup of a host or periodic tasksto a wrapping service.
-
-The :mod:`manager` Module
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The :mod:`nova.manager` Module
+------------------------------
 
 .. automodule:: nova.manager
     :members:
     :undoc-members:
     :show-inheritance:
 
-Driver
-------
+
+Implementation-Specific Drivers
+-------------------------------
 
 A manager will generally load a driver for some of its tasks. The driver is responsible for specific implementation details.  Anything running shell commands on a host, or dealing with other non-python code should probably be happening in a driver.
 
diff --git a/doc/source/devref/volume.rst b/doc/source/devref/volume.rst
index 19b750870..abec38ba8 100644
--- a/doc/source/devref/volume.rst
+++ b/doc/source/devref/volume.rst
@@ -15,8 +15,8 @@
       License for the specific language governing permissions and limitations
       under the License.
 
-Volume Programming Guide
-=========================
+Storage Volumes, Disks
+======================
 
 .. todo:: rework after iSCSI merge (see 'Old Docs') (todd or vish)
 
@@ -41,6 +41,9 @@ The :mod:`nova.volume.driver` Module
 Tests
 -----
 
+The :mod:`volume_unittest` Module
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 .. automodule:: nova.tests.volume_unittest
     :members:
     :undoc-members:
diff --git a/nova/manager.py b/nova/manager.py
index 4244b2db4..a6efb8732 100644
--- a/nova/manager.py
+++ b/nova/manager.py
@@ -15,8 +15,40 @@
 #    WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
 #    License for the specific language governing permissions and limitations
 #    under the License.
+
 """
-Base class for managers of different parts of the system
+Managers are responsible for a certain aspect of the sytem.  It is a logical
+grouping of code relating to a portion of the system.  In general other
+components should be using the manager to make changes to the components that
+it is responsible for.
+
+For example, other components that need to deal with volumes in some way,
+should do so by calling methods on the VolumeManager instead of directly
+changing fields in the database.  This allows us to keep all of the code
+relating to volumes in the same place.
+
+We have adopted a basic strategy of Smart managers and dumb data, which means
+rather than attaching methods to data objects, components should call manager
+methods that act on the data.
+
+Methods on managers that can be executed locally should be called directly. If
+a particular method must execute on a remote host, this should be done via rpc
+to the service that wraps the manager
+
+Managers should be responsible for most of the db access, and
+non-implementation specific data.  Anything implementation specific that can't
+be generalized should be done by the Driver.
+
+In general, we prefer to have one manager with multiple drivers for different
+implementations, but sometimes it makes sense to have multiple managers.  You
+can think of it this way: Abstract different overall strategies at the manager
+level(FlatNetwork vs VlanNetwork), and different implementations at the driver
+level(LinuxNetDriver vs CiscoNetDriver).
+
+Managers will often provide methods for initial setup of a host or periodic
+tasksto a wrapping service.
+
+This module provides Manager, a base class for managers.
 """
 
 from nova import utils
diff --git a/nova/service.py b/nova/service.py
index d53d92b65..0eb3a2762 100644
--- a/nova/service.py
+++ b/nova/service.py
@@ -17,7 +17,11 @@
 #    under the License.
 
 """
-Generic Node baseclass for all workers that run on hosts
+A service is a very thin wrapper around a Manager object.  It exposes the
+manager's public methods to other components of the system via rpc.  It will
+report state periodically to the database and is responsible for initiating any periodic tasts that need to be executed on a given host.
+
+This module contains Service, a generic baseclass for all workers.
 """
 
 import inspect