merge in trunk
This commit is contained in:
commit
b78364281d
@ -4,16 +4,19 @@
|
||||
# You can set these variables from the command line.
|
||||
SPHINXOPTS =
|
||||
SPHINXBUILD = sphinx-build
|
||||
SPHINXSOURCE = source
|
||||
PAPER =
|
||||
BUILDDIR = _build
|
||||
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) .
|
||||
ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) $(SPHINXSOURCE)
|
||||
|
||||
.PHONY: help clean html dirhtml pickle json htmlhelp qthelp latex changes linkcheck doctest
|
||||
|
||||
.DEFAULT_GOAL = html
|
||||
|
||||
help:
|
||||
@echo "Please use \`make <target>' where <target> is one of"
|
||||
@echo " html to make standalone HTML files"
|
||||
@ -29,6 +32,11 @@ help:
|
||||
|
||||
clean:
|
||||
-rm -rf $(BUILDDIR)/*
|
||||
-rm -rf nova.sqlite
|
||||
if [ -f .autogenerated ] ; then \
|
||||
cat .autogenerated | xargs rm ; \
|
||||
rm .autogenerated ; \
|
||||
fi
|
||||
|
||||
html:
|
||||
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
|
33
doc/README.rst
Normal file
33
doc/README.rst
Normal file
@ -0,0 +1,33 @@
|
||||
=================
|
||||
Building the docs
|
||||
=================
|
||||
|
||||
It is really easy. You'll need sphinx (the python one) and if you are using the virtualenv you'll need to install it in the virtualenv specifically so that it can load the nova modules.
|
||||
|
||||
|
||||
Use `make`
|
||||
==========
|
||||
|
||||
Just type make::
|
||||
|
||||
% make
|
||||
|
||||
Look in the Makefile for more targets.
|
||||
|
||||
|
||||
Manually
|
||||
========
|
||||
|
||||
1. Generate the code.rst file so that Sphinx will pull in our docstrings::
|
||||
|
||||
% ./generate_autodoc_index.sh > source/code.rst
|
||||
|
||||
2. Run `sphinx_build`::
|
||||
|
||||
% sphinx-build -b html source build/html
|
||||
|
||||
|
||||
The docs have been built
|
||||
========================
|
||||
|
||||
Check out the `build` directory to find them. Yay!
|
9
doc/ext/nova_autodoc.py
Normal file
9
doc/ext/nova_autodoc.py
Normal file
@ -0,0 +1,9 @@
|
||||
import os
|
||||
|
||||
from nova import utils
|
||||
|
||||
def setup(app):
|
||||
rootdir = os.path.abspath(app.srcdir + '/..')
|
||||
print "**Autodocumenting from %s" % rootdir
|
||||
rv = utils.execute('cd %s && ./generate_autodoc_index.sh' % rootdir)
|
||||
print rv[0]
|
@ -13,8 +13,8 @@ for x in `find ${NOVA_DIR} -name '*.py'`; do
|
||||
done
|
||||
|
||||
for mod in ${modules} ; do
|
||||
op=`grep ${mod} ${DOCS_DIR}/*.rst`
|
||||
if [ -z "${op}" ] ; then
|
||||
echo ${mod}
|
||||
fi
|
||||
if [ ! -f "${DOCS_DIR}/${mod}.rst" ];
|
||||
then
|
||||
echo ${mod}
|
||||
fi
|
||||
done
|
38
doc/generate_autodoc_index.sh
Executable file
38
doc/generate_autodoc_index.sh
Executable file
@ -0,0 +1,38 @@
|
||||
#!/bin/sh
|
||||
|
||||
SOURCEDIR=source/api
|
||||
|
||||
if [ ! -d ${SOURCEDIR} ] ; then
|
||||
mkdir -p ${SOURCEDIR}
|
||||
fi
|
||||
|
||||
for x in `./find_autodoc_modules.sh`;
|
||||
do
|
||||
echo "Generating ${SOURCEDIR}/${x}.rst"
|
||||
echo "${SOURCEDIR}/${x}.rst" >> .autogenerated
|
||||
( cat <<EOF
|
||||
The :mod:\`${x}\` Module
|
||||
==============================================================================
|
||||
.. automodule:: ${x}
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
EOF
|
||||
) > ${SOURCEDIR}/${x}.rst
|
||||
|
||||
done
|
||||
|
||||
if [ ! -f ${SOURCEDIR}/autoindex.rst ] ; then
|
||||
|
||||
cat > ${SOURCEDIR}/autoindex.rst <<EOF
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
EOF
|
||||
for f in `cat .autogenerated | sort` ; do
|
||||
relative=`echo ${f} | sed -e 's$^'${SOURCEDIR}'/$$'`
|
||||
echo " ${relative}" >> ${SOURCEDIR}/autoindex.rst
|
||||
done
|
||||
|
||||
echo ${SOURCEDIR}/autoindex.rst >> .autogenerated
|
||||
fi
|
@ -17,8 +17,8 @@
|
||||
|
||||
.. _binaries:
|
||||
|
||||
Nova Binaries
|
||||
===============
|
||||
Nova Daemons
|
||||
=============
|
||||
|
||||
The configuration of these binaries relies on "flagfiles" using the google
|
||||
gflags package::
|
||||
@ -27,11 +27,6 @@ gflags package::
|
||||
|
||||
The binaries can all run on the same machine or be spread out amongst multiple boxes in a large deployment.
|
||||
|
||||
nova-manage
|
||||
-----------
|
||||
|
||||
Nova manage is a command line utility to administer the system. It will autmatically try to load a flagfile from /etc/nova/nova-manage.conf to save you having to type it. Info on the commands can be found :ref:`here <manage_usage>`.
|
||||
|
||||
nova-api
|
||||
--------
|
||||
|
||||
|
@ -18,12 +18,14 @@
|
||||
Administration Guide
|
||||
====================
|
||||
|
||||
This guide describes the basics of installing and managing Nova. If you havn't yet, you should do the :doc:`../quickstart` before proceeding.
|
||||
This guide describes the basics of running and managing Nova.
|
||||
|
||||
Authentication
|
||||
--------------
|
||||
Running the Cloud
|
||||
-----------------
|
||||
|
||||
.. todo:: Explain authentication
|
||||
The fastest way to get a test cloud running is by following the directions in the :doc:`../quickstart`.
|
||||
|
||||
Nova's cloud works via the interaction of a series of daemon processes that reside persistently on the host machine(s). Fortunately, the :doc:`../quickstart` process launches sample versions of all these daemons for you. Once you are familiar with basic Nova usage, you can learn more about daemons by reading :doc:`../service.architecture` and :doc:`binaries`.
|
||||
|
||||
Administration Utilities
|
||||
------------------------
|
||||
@ -33,14 +35,17 @@ There are two main tools that a system administrator will find useful to manage
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
euca2ools
|
||||
nova.manage
|
||||
euca2ools
|
||||
|
||||
nova-manage may only be run by users with admin priviledges. euca2ools can be used by all users, though specific commands may be restricted by Role Based Access Control. You can read more about creating and managing users in :doc:`managing.users`
|
||||
|
||||
User and Resource Management
|
||||
----------------------------
|
||||
|
||||
nova-manage and euca2ools provide the basic interface to perform a broad range of administration functions. In this section, you can read more about how to accomplish specific administration tasks.
|
||||
nova-manage and euca2ools provide the basic interface to perform a broad range of administration functions. In this section, you can read more about how to accomplish specific administration tasks.
|
||||
|
||||
For background on the core objects refenced in this section, see :doc:`../object.model`
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
@ -59,7 +64,6 @@ Advanced Topics
|
||||
:maxdepth: 1
|
||||
|
||||
multi.node.install
|
||||
binaries
|
||||
flags
|
||||
monitoring
|
||||
|
||||
|
@ -18,8 +18,22 @@
|
||||
Managing Instances
|
||||
==================
|
||||
|
||||
.. todo: cleanup
|
||||
Keypairs
|
||||
--------
|
||||
|
||||
Images can be shared by many users, so it is dangerous to put passwords into the images. Nova therefore supports injecting ssh keys into instances before they are booted. This allows a user to login to the instances that he or she creates securely. Generally the first thing that a user does when using the system is create a keypair. Nova generates a public and private key pair, and sends the private key to the user. The public key is stored so that it can be injected into instances.
|
||||
|
||||
Keypairs are created through the api. They can be created on the command line using the euca2ools script euca-add-keypair. Refer to the man page for the available options. Example usage::
|
||||
|
||||
euca-add-keypair test > test.pem
|
||||
chmod 600 test.pem
|
||||
euca-run-instances -k test -t m1.tiny ami-tiny
|
||||
# wait for boot
|
||||
ssh -i test.pem root@ip.of.instance
|
||||
|
||||
|
||||
Basic Management
|
||||
----------------
|
||||
Instance management can be accomplished with euca commands:
|
||||
|
||||
|
||||
|
@ -20,8 +20,19 @@ Managing Projects
|
||||
|
||||
Projects are isolated resource containers forming the principal organizational structure within Nova. They consist of a separate vlan, volumes, instances, images, keys, and users.
|
||||
|
||||
Basic Commands
|
||||
--------------
|
||||
Although the original ec2 api only supports users, nova adds the concept of projects. A user can specify which project he or she wishes to use by appending `:project_id` to his or her access key. If no project is specified in the api request, nova will attempt to use a project with the same id as the user.
|
||||
|
||||
The api will return NotAuthorized if a normal user attempts to make requests for a project that he or she is not a member of. Note that admins or users with special admin roles skip this check and can make requests for any project.
|
||||
|
||||
To create a project, use the `project create` command of nova-manage. The syntax is nova-manage project create projectname manager_id [description] You must specify a projectname and a manager_id. For example::
|
||||
nova-manage project create john_project john "This is a sample project"
|
||||
|
||||
You can add and remove users from projects with `project add` and `project remove`::
|
||||
nova-manage project add john_project john
|
||||
nova-manage project remove john_project john
|
||||
|
||||
Project Commands
|
||||
----------------
|
||||
|
||||
Admins and Project Managers can use the 'nova-manage project' command to manage project resources:
|
||||
|
||||
|
@ -1,9 +1,38 @@
|
||||
Managing Users
|
||||
==============
|
||||
|
||||
.. todo:: is itsec a valid nova user role?
|
||||
|
||||
.. todo:: need samples of adding/removing user roles
|
||||
Users and Access Keys
|
||||
---------------------
|
||||
|
||||
Access to the ec2 api is controlled by an access and secret key. The user's access key needs to be included in the request, and the request must be signed with the secret key. Upon receipt of api requests, nova will verify the signature and execute commands on behalf of the user.
|
||||
|
||||
In order to begin using nova, you will need a to create a user. This can be easily accomplished using the user create or user admin commands in nova-manage. `user create` will create a regular user, whereas `user admin` will create an admin user. The syntax of the command is nova-manage user create username [access] [secret]. For example::
|
||||
|
||||
nova-manage user create john my-access-key a-super-secret-key
|
||||
|
||||
If you do not specify an access or secret key, a random uuid will be created automatically.
|
||||
|
||||
Credentials
|
||||
-----------
|
||||
|
||||
Nova can generate a handy set of credentials for a user. These credentials include a CA for bundling images and a file for setting environment variables to be used by euca2ools. If you don't need to bundle images, just the environment script is required. You can export one with the `project environment` command. The syntax of the command is nova-manage project environment project_id user_id [filename]. If you don't specify a filename, it will be exported as novarc. After generating the file, you can simply source it in bash to add the variables to your environment::
|
||||
|
||||
nova-manage project environment john_project john
|
||||
. novarc
|
||||
|
||||
If you do need to bundle images, you will need to get all of the credentials using `project zipfile`. Note that zipfile will give you an error message if networks haven't been created yet. Otherwise zipfile has the same syntax as environment, only the default file name is nova.zip. Example usage::
|
||||
|
||||
nova-manage project zipfile john_project john
|
||||
unzip nova.zip
|
||||
. novarc
|
||||
|
||||
Role Based Access Control
|
||||
-------------------------
|
||||
Roles control the api actions that a user is allowed to perform. For example, a user cannot allocate a public ip without the `netadmin` role. It is important to remember that a users de facto permissions in a project is the intersection of user (global) roles and project (local) roles. So for john to have netadmin permissions in his project, he needs to separate roles specified. You can add roles with `role add`. The syntax is nova-manage role add user_id role [project_id]. Let's give john the netadmin role for his project::
|
||||
|
||||
nova-manage role add john netadmin
|
||||
nova-manage role add john netadmin john_project
|
||||
|
||||
Role-based access control (RBAC) is an approach to restricting system access to authorized users based on an individual’s role within an organization. Various employee functions require certain levels of system access in order to be successful. These functions are mapped to defined roles and individuals are categorized accordingly. Since users are not assigned permissions directly, but only acquire them through their role (or roles), management of individual user rights becomes a matter of assigning appropriate roles to the user. This simplifies common operations, such as adding a user, or changing a user's department.
|
||||
|
||||
@ -17,19 +46,9 @@ Nova’s rights management system employs the RBAC model and currently supports
|
||||
|
||||
RBAC management is exposed through the dashboard for simplified user management.
|
||||
|
||||
Nova Administrators
|
||||
-------------------
|
||||
Personnel tasked with user and project administration have access to an additional suite of administrative tools that enable:
|
||||
|
||||
* Adding and Removing Users
|
||||
* Managing user roles
|
||||
* Adding and Removing Projects
|
||||
* Controlling project VPNs
|
||||
* Sending user credentials, including VPN certifications, configuration, and a file useful for command line API access. [#f92]_
|
||||
|
||||
|
||||
User Maintenance
|
||||
~~~~~~~~~~~~~~~~
|
||||
User Commands
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Users, including admins, are created through the ``user`` commands.
|
||||
|
||||
|
@ -17,14 +17,14 @@ import sys, os
|
||||
# add these directories to sys.path here. If the directory is relative to the
|
||||
# documentation root, use os.path.abspath to make it absolute, like shown here.
|
||||
sys.path.insert(0, os.path.abspath('../../'))
|
||||
sys.path.insert(0, '../')
|
||||
sys.path.insert(0, './')
|
||||
sys.path.insert(0, os.path.abspath('../'))
|
||||
sys.path.insert(0, os.path.abspath('./'))
|
||||
|
||||
# -- General configuration -----------------------------------------------------
|
||||
|
||||
# Add any Sphinx extension module names here, as strings. They can be extensions
|
||||
# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
|
||||
extensions = ['sphinx.ext.autodoc', 'sphinx.ext.intersphinx', 'ext.nova_todo', 'sphinx.ext.coverage', 'sphinx.ext.pngmath', 'sphinx.ext.ifconfig','sphinx.ext.graphviz']
|
||||
extensions = ['sphinx.ext.autodoc', 'sphinx.ext.intersphinx', 'ext.nova_todo', 'sphinx.ext.coverage', 'sphinx.ext.pngmath', 'sphinx.ext.ifconfig','sphinx.ext.graphviz', 'ext.nova_autodoc']
|
||||
todo_include_todos = True
|
||||
|
||||
# Add any paths that contain templates here, relative to this directory.
|
||||
|
@ -15,10 +15,8 @@
|
||||
License for the specific language governing permissions and limitations
|
||||
under the License.
|
||||
|
||||
API Endpoint Programming Guide
|
||||
==============================
|
||||
|
||||
.. todo:: get actual docstrings from ec2/osapi_verions instead of @wsgify
|
||||
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
|
||||
@ -29,16 +27,17 @@ Common Components
|
||||
|
||||
The :mod:`nova.api` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.api
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`cloud` Module
|
||||
The :mod:`nova.api.cloud` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.api.cloud
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -49,6 +48,7 @@ OpenStack API
|
||||
The :mod:`openstack` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
.. automodule:: nova.api.openstack
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -56,6 +56,7 @@ The :mod:`openstack` Module
|
||||
The :mod:`auth` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
.. automodule:: nova.api.openstack.auth
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -63,6 +64,7 @@ The :mod:`auth` Module
|
||||
The :mod:`backup_schedules` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
.. automodule:: nova.api.openstack.backup_schedules
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -70,6 +72,7 @@ The :mod:`backup_schedules` Module
|
||||
The :mod:`faults` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
.. automodule:: nova.api.openstack.faults
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -77,6 +80,7 @@ The :mod:`faults` Module
|
||||
The :mod:`flavors` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
.. automodule:: nova.api.openstack.flavors
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -84,6 +88,7 @@ The :mod:`flavors` Module
|
||||
The :mod:`images` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
.. automodule:: nova.api.openstack.images
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -91,6 +96,7 @@ The :mod:`images` Module
|
||||
The :mod:`ratelimiting` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
.. automodule:: nova.api.openstack.ratelimiting
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -98,6 +104,7 @@ The :mod:`ratelimiting` Module
|
||||
The :mod:`servers` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
.. automodule:: nova.api.openstack.servers
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -105,6 +112,7 @@ The :mod:`servers` Module
|
||||
The :mod:`sharedipgroups` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
.. automodule:: nova.api.openstack.sharedipgroups
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -116,6 +124,7 @@ The :mod:`nova.api.ec2` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.api.ec2
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -124,6 +133,7 @@ The :mod:`admin` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.api.ec2.admin
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -132,6 +142,7 @@ The :mod:`apirequest` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.api.ec2.apirequest
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -140,6 +151,7 @@ The :mod:`cloud` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.api.ec2.cloud
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -148,6 +160,7 @@ The :mod:`images` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.api.ec2.images
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -156,6 +169,7 @@ The :mod:`metadatarequesthandler` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.api.ec2.metadatarequesthandler
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -167,6 +181,7 @@ The :mod:`api_unittest` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.api_unittest
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -175,6 +190,7 @@ The :mod:`api_integration` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.api_integration
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -183,6 +199,7 @@ The :mod:`cloud_unittest` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.cloud_unittest
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -191,6 +208,7 @@ The :mod:`api.fakes` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.api.fakes
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -199,6 +217,7 @@ The :mod:`api.test_wsgi` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.api.test_wsgi
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -207,6 +226,7 @@ The :mod:`test_api` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.api.openstack.test_api
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -215,6 +235,7 @@ The :mod:`test_auth` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.api.openstack.test_auth
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -223,6 +244,7 @@ The :mod:`test_faults` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.api.openstack.test_faults
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -231,6 +253,7 @@ The :mod:`test_flavors` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.api.openstack.test_flavors
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -239,6 +262,7 @@ The :mod:`test_images` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.api.openstack.test_images
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -247,6 +271,7 @@ The :mod:`test_ratelimiting` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.api.openstack.test_ratelimiting
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -255,6 +280,7 @@ The :mod:`test_servers` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.api.openstack.test_servers
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -263,6 +289,7 @@ The :mod:`test_sharedipgroups` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.api.openstack.test_sharedipgroups
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
@ -17,86 +17,96 @@
|
||||
|
||||
.. _auth:
|
||||
|
||||
Authentication and Authorization Programming Guide
|
||||
==================================================
|
||||
Authentication and Authorization
|
||||
================================
|
||||
|
||||
The :mod:`quota` Module
|
||||
-----------------------
|
||||
The :mod:`nova.quota` Module
|
||||
----------------------------
|
||||
|
||||
.. automodule:: nova.quota
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :mod:`nova.auth.signer` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.auth.signer
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
Auth Manager
|
||||
------------
|
||||
|
||||
The :mod:`manager` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
The :mod:`nova.auth.manager` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.auth.manager
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
Drivers
|
||||
-------
|
||||
|
||||
The :mod:`ldapdriver` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
The :mod:`nova.auth.ldapdriver` Driver
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.auth.ldapdriver
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`dbdriver` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
The :mod:`nova.auth.dbdriver` Driver
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.auth.dbdriver
|
||||
:noindex:
|
||||
:members:
|
||||
: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
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.auth_unittest
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :mod:`access_unittest` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.access_unittest
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :mod:`quota_unittest` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.quota_unittest
|
||||
:noindex:
|
||||
:members:
|
||||
: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 +114,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 +137,7 @@ In more ideal implementations, the remainder of the application-specific account
|
||||
|
||||
.. _auth_roles:
|
||||
|
||||
|
||||
Roles
|
||||
-----
|
||||
|
||||
@ -172,6 +185,7 @@ Cloud Administrator/IT-Security:
|
||||
|
||||
* All permissions
|
||||
|
||||
|
||||
Enhancements
|
||||
------------
|
||||
|
||||
@ -182,6 +196,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 +207,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 +219,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 +244,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 +269,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
|
@ -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,18 +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:`crypto` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The :mod:`nova.api.cloudpipe` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.api.cloudpipe
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :mod:`nova.crypto` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.crypto
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
@ -16,64 +16,69 @@
|
||||
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
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`connection` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
The :mod:`nova.virt.connection` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.virt.connection
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`disk` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
The :mod:`nova.compute.disk` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.compute.disk
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`images` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
The :mod:`nova.virt.images` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.virt.images
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :mod:`instance_types` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
The :mod:`nova.compute.instance_types` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.compute.instance_types
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :mod:`power_state` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
The :mod:`nova.compute.power_state` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.compute.power_state
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -82,45 +87,45 @@ 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
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
XEN
|
||||
~~~
|
||||
|
||||
The :mod:`xenapi` Module
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
The :mod:`nova.virt.xenapi` Driver
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.virt.xenapi
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
FAKE
|
||||
~~~~
|
||||
|
||||
The :mod:`nova.virt.fake` Driver
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.virt.fake
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
Monitoring
|
||||
----------
|
||||
|
||||
The :mod:`monitor` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
The :mod:`nova.compute.monitor` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.compute.monitor
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -133,6 +138,7 @@ The :mod:`compute_unittest` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.compute_unittest
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -141,6 +147,7 @@ The :mod:`virt_unittest` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.virt_unittest
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
@ -15,45 +15,47 @@
|
||||
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
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
Drivers
|
||||
-------
|
||||
The Sqlalchemy Driver
|
||||
---------------------
|
||||
|
||||
Driver: Sqlalchemy
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The :mod:`sqlalchemy.api` Module
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
The :mod:`nova.db.sqlalchemy.api` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.db.sqlalchemy.api
|
||||
:noindex:
|
||||
|
||||
The :mod:`sqlalchemy.models` Module
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
The :mod:`nova.db.sqlalchemy.models` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.db.sqlalchemy.models
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`sqlalchemy.session` Module
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
The :mod:`nova.db.sqlalchemy.session` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.db.sqlalchemy.session
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
Tests
|
||||
-----
|
||||
|
@ -15,57 +15,70 @@
|
||||
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
|
||||
---------------------------
|
||||
|
||||
.. automodule:: nova.virt.fake
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
:noindex:
|
||||
|
||||
The :mod:`fakeldap` Module
|
||||
--------------------------
|
||||
|
||||
.. automodule:: nova.auth.fakeldap
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`fakerabbit` Module
|
||||
----------------------------
|
||||
|
||||
.. automodule:: nova.fakerabbit
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :class:`FakeAOEDriver` Class
|
||||
The :mod:`nova.virt.fake` Module
|
||||
--------------------------------
|
||||
|
||||
.. autoclass:: nova.volume.driver.FakeAOEDriver
|
||||
.. automodule:: nova.virt.fake
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :class:`service_unittest.FakeManager` Class
|
||||
-----------------------------------------------
|
||||
|
||||
The :mod:`nova.auth.fakeldap` Module
|
||||
------------------------------------
|
||||
|
||||
.. automodule:: nova.auth.fakeldap
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :mod:`nova.fakerabbit` Module
|
||||
---------------------------------
|
||||
|
||||
.. automodule:: nova.fakerabbit
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :class:`nova.volume.driver.FakeAOEDriver` Class
|
||||
---------------------------------------------------
|
||||
|
||||
.. autoclass:: nova.volume.driver.FakeAOEDriver
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :class:`nova.tests.service_unittest.FakeManager` Class
|
||||
----------------------------------------------------------
|
||||
|
||||
.. autoclass:: nova.tests.service_unittest.FakeManager
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`api.openstack.fakes` Module
|
||||
|
||||
The :mod:`nova.tests.api.openstack.fakes` Module
|
||||
------------------------------------------------
|
||||
|
||||
.. automodule:: nova.tests.api.openstack.fakes
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
@ -15,13 +15,14 @@
|
||||
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
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
@ -20,16 +20,23 @@ Developer Guide
|
||||
|
||||
In this section you will find information on Nova's lower level programming APIs.
|
||||
|
||||
|
||||
Programming HowTos and Tutorials
|
||||
--------------------------------
|
||||
|
||||
.. todo:: Add some programming howtos and tuts
|
||||
|
||||
API Reference
|
||||
-------------
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
|
||||
../api/autoindex
|
||||
|
||||
Module Reference
|
||||
----------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:maxdepth: 3
|
||||
|
||||
services
|
||||
database
|
@ -15,26 +15,29 @@
|
||||
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
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`LinuxNet` driver
|
||||
--------------------------
|
||||
The :mod:`nova.network.linux_net` Driver
|
||||
----------------------------------------
|
||||
|
||||
.. automodule:: nova.network.linux_net
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -46,12 +49,13 @@ The :mod:`network_unittest` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.network_unittest
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
legacy docs
|
||||
Legacy docs
|
||||
-----------
|
||||
|
||||
The nova networking components manage private networks, public IP addressing, VPN connectivity, and firewall rules.
|
@ -15,105 +15,133 @@
|
||||
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
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`context` Module
|
||||
-------------------------
|
||||
|
||||
The :mod:`nova.context` Module
|
||||
------------------------------
|
||||
|
||||
.. automodule:: nova.context
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`exception` Module
|
||||
---------------------------
|
||||
|
||||
The :mod:`nova.exception` Module
|
||||
--------------------------------
|
||||
|
||||
.. automodule:: nova.exception
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`flags` Module
|
||||
-----------------------
|
||||
|
||||
The :mod:`nova.flags` Module
|
||||
----------------------------
|
||||
|
||||
.. automodule:: nova.flags
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`process` Module
|
||||
-------------------------
|
||||
|
||||
The :mod:`nova.process` Module
|
||||
------------------------------
|
||||
|
||||
.. automodule:: nova.process
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`rpc` Module
|
||||
---------------------
|
||||
|
||||
.. automodule:: nova.rpc
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`server` Module
|
||||
------------------------
|
||||
|
||||
.. automodule:: nova.server
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`test` Module
|
||||
----------------------
|
||||
|
||||
.. automodule:: nova.test
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`twistd` Module
|
||||
------------------------
|
||||
|
||||
.. automodule:: nova.twistd
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`utils` Module
|
||||
-----------------------
|
||||
|
||||
.. automodule:: nova.utils
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`validate` Module
|
||||
The :mod:`nova.rpc` Module
|
||||
--------------------------
|
||||
|
||||
.. automodule:: nova.validate
|
||||
.. automodule:: nova.rpc
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`wsgi` Module
|
||||
----------------------
|
||||
|
||||
The :mod:`nova.server` Module
|
||||
-----------------------------
|
||||
|
||||
.. automodule:: nova.server
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :mod:`nova.test` Module
|
||||
---------------------------
|
||||
|
||||
.. automodule:: nova.test
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :mod:`nova.twistd` Module
|
||||
-----------------------------
|
||||
|
||||
.. automodule:: nova.twistd
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :mod:`nova.utils` Module
|
||||
----------------------------
|
||||
|
||||
.. automodule:: nova.utils
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :mod:`nova.validate` Module
|
||||
-------------------------------
|
||||
|
||||
.. automodule:: nova.validate
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :mod:`nova.wsgi` Module
|
||||
---------------------------
|
||||
|
||||
.. automodule:: nova.wsgi
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
Tests
|
||||
-----
|
||||
|
||||
@ -121,70 +149,87 @@ The :mod:`declare_flags` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.declare_flags
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :mod:`fake_flags` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.fake_flags
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :mod:`flags_unittest` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.flags_unittest
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :mod:`process_unittest` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.process_unittest
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :mod:`real_flags` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.real_flags
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :mod:`rpc_unittest` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.rpc_unittest
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :mod:`runtime_flags` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.runtime_flags
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :mod:`twistd_unittest` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.twistd_unittest
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
The :mod:`validator_unittest` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.validator_unittest
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
@ -15,41 +15,49 @@
|
||||
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
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`bucket` Module
|
||||
------------------------
|
||||
|
||||
The :mod:`nova.objectstore.bucket` Module
|
||||
-----------------------------------------
|
||||
|
||||
.. automodule:: nova.objectstore.bucket
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`stored` Module
|
||||
------------------------
|
||||
|
||||
The :mod:`nova.objectstore.stored` Module
|
||||
-----------------------------------------
|
||||
|
||||
.. automodule:: nova.objectstore.stored
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`image` Module
|
||||
-----------------------
|
||||
|
||||
The :mod:`nova.objecstore.image` Module
|
||||
----------------------------------------
|
||||
|
||||
.. automodule:: nova.objectstore.image
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
Tests
|
||||
-----
|
||||
|
||||
@ -57,6 +65,7 @@ The :mod:`objectstore_unittest` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.objectstore_unittest
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
@ -15,41 +15,49 @@
|
||||
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
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`driver` Module
|
||||
------------------------
|
||||
|
||||
The :mod:`nova.scheduler.driver` Module
|
||||
---------------------------------------
|
||||
|
||||
.. automodule:: nova.scheduler.driver
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`chance` Module
|
||||
------------------------
|
||||
|
||||
The :mod:`nova.scheduler.chance` Driver
|
||||
---------------------------------------
|
||||
|
||||
.. automodule:: nova.scheduler.chance
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`simple` Module
|
||||
------------------------
|
||||
|
||||
The :mod:`nova.scheduler.simple` Driver
|
||||
---------------------------------------
|
||||
|
||||
.. automodule:: nova.scheduler.simple
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
Tests
|
||||
-----
|
||||
|
||||
@ -57,6 +65,7 @@ The :mod:`scheduler_unittest` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.scheduler_unittest
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
@ -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.
|
||||
|
@ -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)
|
||||
|
||||
@ -25,6 +25,7 @@ The :mod:`nova.volume.manager` Module
|
||||
-------------------------------------
|
||||
|
||||
.. automodule:: nova.volume.manager
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -33,6 +34,7 @@ The :mod:`nova.volume.driver` Module
|
||||
-------------------------------------
|
||||
|
||||
.. automodule:: nova.volume.driver
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -41,7 +43,11 @@ The :mod:`nova.volume.driver` Module
|
||||
Tests
|
||||
-----
|
||||
|
||||
The :mod:`volume_unittest` Module
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. automodule:: nova.tests.volume_unittest
|
||||
:noindex:
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
@ -55,10 +55,9 @@ Using Nova
|
||||
|
||||
quickstart
|
||||
adminguide/index
|
||||
devguide/index
|
||||
devref/index
|
||||
community
|
||||
|
||||
|
||||
Outstanding Documentation Tasks
|
||||
===============================
|
||||
|
||||
|
@ -45,10 +45,55 @@ Nova is hosted on launchpad. You can get the code with the following command
|
||||
|
||||
bzr clone lp:nova
|
||||
|
||||
The `contrib/novascript.sh` file in the source distribution is a script that
|
||||
The `contrib/nova.sh` file in the source distribution is a script that
|
||||
will quickly set up nova to run on a single machine. It is tested against
|
||||
Ubuntu only, but other distributions are forthcoming.
|
||||
|
||||
Environment Variables
|
||||
---------------------
|
||||
|
||||
By tweaking the environment that nova.sh run in, you can build slightly
|
||||
different configurations (though for more complex setups you should see
|
||||
:doc:`/adminguide/getting.started` and :doc:`/adminguide/multi.node.install`).
|
||||
|
||||
HOST_IP
|
||||
~~~~~~~
|
||||
|
||||
**Default**: address of first interface from the ifconfig command
|
||||
**Values**: 127.0.0.1, or any other valid address
|
||||
|
||||
TEST
|
||||
~~~~
|
||||
|
||||
**Default**: 0
|
||||
**Values**: 1, run tests after checkout and initial setup
|
||||
|
||||
USE_MYSQL
|
||||
~~~~~~~~~
|
||||
|
||||
**Default**: 0, use sqlite3
|
||||
**Values**: 1, use mysql instead of sqlite3
|
||||
|
||||
MYSQL_PASS
|
||||
~~~~~~~~~~
|
||||
|
||||
Only useful if $USE_MYSQL=1.
|
||||
|
||||
**Default**: nova
|
||||
**Values**: value of root password for mysql
|
||||
|
||||
USE_LDAP
|
||||
~~~~~~~~
|
||||
|
||||
**Default**: 0, use :mod:`nova.auth.dbdriver`
|
||||
**Values**: 1, use :mod:`nova.auth.ldapdriver`
|
||||
|
||||
LIBVIRT_TYPE
|
||||
~~~~~~~~~~~~
|
||||
|
||||
**Default**: qemu
|
||||
**Values**: uml, kvm
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
|
@ -30,6 +30,7 @@ import routes
|
||||
import webob.dec
|
||||
|
||||
from nova import flags
|
||||
from nova import utils
|
||||
from nova import wsgi
|
||||
from nova.api import cloudpipe
|
||||
from nova.api import ec2
|
||||
@ -83,6 +84,7 @@ class API(wsgi.Router):
|
||||
mapper.connect("/cloudpipe/{path_info:.*}", controller=cloudpipe.API())
|
||||
super(API, self).__init__(mapper)
|
||||
|
||||
@utils.fix_wsgify_docstr
|
||||
@webob.dec.wsgify
|
||||
def osapi_versions(self, req):
|
||||
"""Respond to a request for all OpenStack API versions."""
|
||||
@ -94,6 +96,7 @@ class API(wsgi.Router):
|
||||
"attributes": dict(version=["status", "id"])}}
|
||||
return wsgi.Serializer(req.environ, metadata).to_content_type(response)
|
||||
|
||||
@utils.fix_wsgify_docstr
|
||||
@webob.dec.wsgify
|
||||
def ec2api_versions(self, req):
|
||||
"""Respond to a request for all EC2 versions."""
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -21,6 +21,7 @@ System-level utilities and helper functions.
|
||||
"""
|
||||
|
||||
import datetime
|
||||
import functools
|
||||
import inspect
|
||||
import logging
|
||||
import os
|
||||
@ -232,3 +233,10 @@ def utf8(value):
|
||||
return value.encode("utf-8")
|
||||
assert isinstance(value, str)
|
||||
return value
|
||||
|
||||
def fix_wsgify_docstr(wsgified_func):
|
||||
"""A decorator to re-assign docstrings that webob.dec.wsgify clobbers."""
|
||||
@functools.wraps(wsgified_func.func)
|
||||
def _f(*args, **kwargs):
|
||||
wsgified_func(*args, **kwargs)
|
||||
return _f
|
||||
|
Loading…
Reference in New Issue
Block a user