Merge termie's autodoc system into trunkdoc.

18 files changed, 42 insertions, 140 deletions

diff --git a/doc/source/Makefile b/doc/source/Makefile
deleted file mode 100644
index b2f74e85a..000000000
--- a/doc/source/Makefile
+++ /dev/null
@@ -1,89 +0,0 @@
-# Makefile for Sphinx documentation
-#
-
-# You can set these variables from the command line.
-SPHINXOPTS    =
-SPHINXBUILD   = sphinx-build
-PAPER         =
-BUILDDIR      = _build
-
-# Internal variables.
-PAPEROPT_a4     = -D latex_paper_size=a4
-PAPEROPT_letter = -D latex_paper_size=letter
-ALLSPHINXOPTS   = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
-
-.PHONY: help clean html dirhtml pickle json htmlhelp qthelp latex changes linkcheck doctest
-
-help:
-	@echo "Please use \`make <target>' where <target> is one of"
-	@echo "  html      to make standalone HTML files"
-	@echo "  dirhtml   to make HTML files named index.html in directories"
-	@echo "  pickle    to make pickle files"
-	@echo "  json      to make JSON files"
-	@echo "  htmlhelp  to make HTML files and a HTML help project"
-	@echo "  qthelp    to make HTML files and a qthelp project"
-	@echo "  latex     to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
-	@echo "  changes   to make an overview of all changed/added/deprecated items"
-	@echo "  linkcheck to check all external links for integrity"
-	@echo "  doctest   to run all doctests embedded in the documentation (if enabled)"
-
-clean:
-	-rm -rf $(BUILDDIR)/*
-
-html:
-	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
-	@echo
-	@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
-
-dirhtml:
-	$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
-	@echo
-	@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
-
-pickle:
-	$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
-	@echo
-	@echo "Build finished; now you can process the pickle files."
-
-json:
-	$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
-	@echo
-	@echo "Build finished; now you can process the JSON files."
-
-htmlhelp:
-	$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
-	@echo
-	@echo "Build finished; now you can run HTML Help Workshop with the" \
-	      ".hhp project file in $(BUILDDIR)/htmlhelp."
-
-qthelp:
-	$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
-	@echo
-	@echo "Build finished; now you can run "qcollectiongenerator" with the" \
-	      ".qhcp project file in $(BUILDDIR)/qthelp, like this:"
-	@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/nova.qhcp"
-	@echo "To view the help file:"
-	@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/nova.qhc"
-
-latex:
-	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
-	@echo
-	@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
-	@echo "Run \`make all-pdf' or \`make all-ps' in that directory to" \
-	      "run these through (pdf)latex."
-
-changes:
-	$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
-	@echo
-	@echo "The overview file is in $(BUILDDIR)/changes."
-
-linkcheck:
-	$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
-	@echo
-	@echo "Link check complete; look for any errors in the above output " \
-	      "or in $(BUILDDIR)/linkcheck/output.txt."
-
-doctest:
-	$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
-	@echo "Testing of doctests in the sources finished, look at the " \
-	      "results in $(BUILDDIR)/doctest/output.txt."
diff --git a/doc/source/devguide/api.rst b/doc/source/devref/api.rst
index cad0e820a..cad0e820a 100644
--- a/doc/source/devguide/api.rst
+++ b/doc/source/devref/api.rst
diff --git a/doc/source/devguide/architecture.rst b/doc/source/devref/architecture.rst
index 1e23e1361..1e23e1361 100644
--- a/doc/source/devguide/architecture.rst
+++ b/doc/source/devref/architecture.rst
diff --git a/doc/source/devguide/auth.rst b/doc/source/devref/auth.rst
index 77d97f68b..77d97f68b 100644
--- a/doc/source/devguide/auth.rst
+++ b/doc/source/devref/auth.rst
diff --git a/doc/source/devguide/cloudpipe.rst b/doc/source/devref/cloudpipe.rst
index 5264a0f39..31bd85e81 100644
--- a/doc/source/devguide/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,26 +63,32 @@ 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
+    :noindex:
     :members:
     :undoc-members:
     :show-inheritance:
 
-The :mod:`api.cloudpipe` Module
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The :mod:`nova.api.cloudpipe` Module
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.api.cloudpipe
+    :noindex:
     :members:
     :undoc-members:
     :show-inheritance:
 
-The :mod:`crypto` Module
-~~~~~~~~~~~~~~~~~~~~~~~~
+
+The :mod:`nova.crypto` Module
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: nova.crypto
+    :noindex:
     :members:
     :undoc-members:
     :show-inheritance:
diff --git a/doc/source/devguide/compute.rst b/doc/source/devref/compute.rst
index e4c6c6ae7..e4c6c6ae7 100644
--- a/doc/source/devguide/compute.rst
+++ b/doc/source/devref/compute.rst
diff --git a/doc/source/devguide/database.rst b/doc/source/devref/database.rst
index b58ea147d..b58ea147d 100644
--- a/doc/source/devguide/database.rst
+++ b/doc/source/devref/database.rst
diff --git a/doc/source/devguide/development.environment.rst b/doc/source/devref/development.environment.rst
index 34104c964..34104c964 100644
--- a/doc/source/devguide/development.environment.rst
+++ b/doc/source/devref/development.environment.rst
diff --git a/doc/source/devguide/fakes.rst b/doc/source/devref/fakes.rst
index 61622754c..61622754c 100644
--- a/doc/source/devguide/fakes.rst
+++ b/doc/source/devref/fakes.rst
diff --git a/doc/source/devguide/glance.rst b/doc/source/devref/glance.rst
index 3d0f4ebec..3d0f4ebec 100644
--- a/doc/source/devguide/glance.rst
+++ b/doc/source/devref/glance.rst
diff --git a/doc/source/devguide/index.rst b/doc/source/devref/index.rst
index 6232a3181..66deabf2d 100644
--- a/doc/source/devguide/index.rst
+++ b/doc/source/devref/index.rst
@@ -15,13 +15,14 @@
       License for the specific language governing permissions and limitations
       under the License.
 
-Nova Development Guide
-======================
+Nova Development Reference
+==========================
 
-Nova is written in python.
+Nova is written in Python.
 
 Prerequisites
 -------------
+
 .. toctree::
    :maxdepth: 1
 
@@ -30,25 +31,22 @@ Prerequisites
    development.environment
 
 
-Contents
---------
+Guides
+------
 
 .. toctree::
    :maxdepth: 1
 
    services
-   database
-   volume
-   compute
-   network
-   auth
-   api
-   scheduler
-   fakes
-   nova
    cloudpipe
-   objectstore
-   glance
+
+API Reference
+-------------
+
+.. toctree::
+    :glob:
+
+    /api/*
 
 
 Indices and tables
diff --git a/doc/source/devguide/network.rst b/doc/source/devref/network.rst
index 318286383..318286383 100644
--- a/doc/source/devguide/network.rst
+++ b/doc/source/devref/network.rst
diff --git a/doc/source/devguide/nova.rst b/doc/source/devref/nova.rst
index 58125dc80..58125dc80 100644
--- a/doc/source/devguide/nova.rst
+++ b/doc/source/devref/nova.rst
diff --git a/doc/source/devguide/objectstore.rst b/doc/source/devref/objectstore.rst
index 4087b5dd0..4087b5dd0 100644
--- a/doc/source/devguide/objectstore.rst
+++ b/doc/source/devref/objectstore.rst
diff --git a/doc/source/devguide/scheduler.rst b/doc/source/devref/scheduler.rst
index df820c2f2..df820c2f2 100644
--- a/doc/source/devguide/scheduler.rst
+++ b/doc/source/devref/scheduler.rst
diff --git a/doc/source/devguide/services.rst b/doc/source/devref/services.rst
index 517a51901..f5bba5c12 100644
--- a/doc/source/devguide/services.rst
+++ b/doc/source/devref/services.rst
@@ -17,53 +17,36 @@
 
 .. _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
+    :noindex:
     :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
+    :noindex:
     :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/devguide/volume.rst b/doc/source/devref/volume.rst
index 19b750870..19b750870 100644
--- a/doc/source/devguide/volume.rst
+++ b/doc/source/devref/volume.rst
diff --git a/doc/source/index.rst b/doc/source/index.rst
index 4ef75c432..f96d5ff80 100644
--- a/doc/source/index.rst
+++ b/doc/source/index.rst
@@ -45,7 +45,7 @@ Contents
 
    concepts.and.introduction
    adminguide/index
-   devguide/index
+   devref/index
    reaching.out
 
 Recommended System Configuration