Several documentation corrections
This commit is contained in:
Cory Wright
parent
0880026253
commit
f5611d9fde
@ -77,21 +77,20 @@ Nova development has consolidated all .conf files to nova.conf as of November 20
|
||||
|
||||
#. These need to be defined in the nova.conf configuration file::
|
||||
|
||||
--sql_connection=mysql://root:nova@$CC_ADDR/nova # location of nova sql db
|
||||
--s3_host=$CC_ADDR # This is where nova is hosting the objectstore service, which
|
||||
# will contain the VM images and buckets
|
||||
--rabbit_host=$CC_ADDR # This is where the rabbit AMQP messaging service is hosted
|
||||
--cc_host=$CC_ADDR # This is where the the nova-api service lives
|
||||
--verbose # Optional but very helpful during initial setup
|
||||
--ec2_url=http://$CC_ADDR:8773/services/Cloud
|
||||
--network_manager=nova.network.manager.FlatManager # simple, no-vlan networking type
|
||||
|
||||
--fixed_range=<network/prefix> # ip network to use for VM guests, ex 192.168.2.64/26
|
||||
--network_size=<# of addrs> # number of ip addrs to use for VM guests, ex 64
|
||||
--sql_connection=mysql://root:nova@$CC_ADDR/nova # location of nova sql db
|
||||
--s3_host=$CC_ADDR # This is where Nova is hosting the objectstore service, which
|
||||
# will contain the VM images and buckets
|
||||
--rabbit_host=$CC_ADDR # This is where the rabbit AMQP messaging service is hosted
|
||||
--cc_host=$CC_ADDR # This is where the the nova-api service lives
|
||||
--verbose # Optional but very helpful during initial setup
|
||||
--ec2_url=http://$CC_ADDR:8773/services/Cloud
|
||||
--network_manager=nova.network.manager.FlatManager # simple, no-vlan networking type
|
||||
--fixed_range=<network/prefix> # ip network to use for VM guests, ex 192.168.2.64/26
|
||||
--network_size=<# of addrs> # number of ip addrs to use for VM guests, ex 64
|
||||
|
||||
#. Create a nova group::
|
||||
|
||||
sudo addgroup nova
|
||||
sudo addgroup nova
|
||||
|
||||
The Nova config file should have its owner set to root:nova, and mode set to 0640, since they contain your MySQL server's root password.
|
||||
|
||||
|
||||
@ -24,7 +24,7 @@ Routing
|
||||
|
||||
To map URLs to controllers+actions, OpenStack uses the Routes package, a clone of Rails routes for Python implementations. See http://routes.groovie.org/ fore more information.
|
||||
|
||||
URLs are mapped to "action" methods on "controller" classes in nova/api/openstack/__init__/ApiRouter.__init__ .
|
||||
URLs are mapped to "action" methods on "controller" classes in `nova/api/openstack/__init__/ApiRouter.__init__` .
|
||||
|
||||
See http://routes.groovie.org/manual.html for all syntax, but you'll probably just need these two:
|
||||
- mapper.connect() lets you map a single URL to a single action on a controller.
|
||||
@ -33,9 +33,9 @@ See http://routes.groovie.org/manual.html for all syntax, but you'll probably ju
|
||||
Controllers and actions
|
||||
-----------------------
|
||||
|
||||
Controllers live in nova/api/openstack, and inherit from nova.wsgi.Controller.
|
||||
Controllers live in `nova/api/openstack`, and inherit from nova.wsgi.Controller.
|
||||
|
||||
See nova/api/openstack/servers.py for an example.
|
||||
See `nova/api/openstack/servers.py` for an example.
|
||||
|
||||
Action methods take parameters that are sucked out of the URL by mapper.connect() or .resource(). The first two parameters are self and the WebOb request, from which you can get the req.environ, req.body, req.headers, etc.
|
||||
|
||||
@ -46,7 +46,7 @@ Actions return a dictionary, and wsgi.Controller serializes that to JSON or XML
|
||||
|
||||
If you define a new controller, you'll need to define a _serialization_metadata attribute on the class, to tell wsgi.Controller how to convert your dictionary to XML. It needs to know the singular form of any list tag (e.g. <servers> list contains <server> tags) and which dictionary keys are to be XML attributes as opposed to subtags (e.g. <server id="4"/> instead of <server><id>4</id></server>).
|
||||
|
||||
See nova/api/openstack/servers.py for an example.
|
||||
See `nova/api/openstack/servers.py` for an example.
|
||||
|
||||
Faults
|
||||
------
|
||||
|
||||
@ -71,8 +71,8 @@ RPC Casts
|
||||
|
||||
The diagram below the message flow during an rp.cast operation:
|
||||
|
||||
1. a Topic Publisher is instantiated to send the message request to the queuing system.
|
||||
2. once the message is dispatched by the exchange, it is fetched by the Topic Consumer dictated by the routing key (such as 'topic') and passed to the Worker in charge of the task.
|
||||
1. A Topic Publisher is instantiated to send the message request to the queuing system.
|
||||
2. Once the message is dispatched by the exchange, it is fetched by the Topic Consumer dictated by the routing key (such as 'topic') and passed to the Worker in charge of the task.
|
||||
|
||||
.. image:: /images/rabbit/flow2.png
|
||||
:width: 60%
|
||||
|
||||
@ -75,7 +75,7 @@ Nova is built on a shared-nothing, messaging-based architecture. All of the majo
|
||||
|
||||
To achieve the shared-nothing property with multiple copies of the same component, Nova keeps all the cloud system state in a distributed data store. Updates to system state are written into this store, using atomic transactions when required. Requests for system state are read out of this store. In limited cases, the read results are cached within controllers for short periods of time (for example, the current list of system users.)
|
||||
|
||||
.. note:: The database schema is available on the `OpenStack Wiki <http://wiki.openstack.org/NovaDatabaseSchema>_`.
|
||||
.. note:: The database schema is available on the `OpenStack Wiki <http://wiki.openstack.org/NovaDatabaseSchema>`_.
|
||||
|
||||
Concept: Storage
|
||||
----------------
|
||||
@ -129,12 +129,12 @@ The simplest networking mode. Each instance receives a fixed ip from the pool.
|
||||
Flat DHCP Mode
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
This is similar to the flat mode, in that all instances are attached to the same bridge. In this mode nova does a bit more configuration, it will attempt to bridge into an ethernet device (eth0 by default). It will also run dnsmasq as a dhcpserver listening on this bridge. Instances receive their fixed IPs by doing a dhcpdiscover.
|
||||
This is similar to the flat mode, in that all instances are attached to the same bridge. In this mode Nova does a bit more configuration, it will attempt to bridge into an ethernet device (eth0 by default). It will also run dnsmasq as a dhcpserver listening on this bridge. Instances receive their fixed IPs by doing a dhcpdiscover.
|
||||
|
||||
VLAN DHCP Mode
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
This is the default networking mode and supports the most features. For multiple machine installation, it requires a switch that supports host-managed vlan tagging. In this mode, nova will create a vlan and bridge for each project. The project gets a range of private ips that are only accessible from inside the vlan. In order for a user to access the instances in their project, a special vpn instance (code named :ref:`cloudpipe <cloudpipe>`) needs to be created. Nova generates a certificate and key for the user to access the vpn and starts the vpn automatically. More information on cloudpipe can be found :ref:`here <cloudpipe>`.
|
||||
This is the default networking mode and supports the most features. For multiple machine installation, it requires a switch that supports host-managed vlan tagging. In this mode, Nova will create a vlan and bridge for each project. The project gets a range of private ips that are only accessible from inside the vlan. In order for a user to access the instances in their project, a special vpn instance (code named :ref:`cloudpipe <cloudpipe>`) needs to be created. Nova generates a certificate and key for the user to access the vpn and starts the vpn automatically. More information on cloudpipe can be found :ref:`here <cloudpipe>`.
|
||||
|
||||
The following diagram illustrates how the communication that occurs between the vlan (the dashed box) and the public internet (represented by the two clouds)
|
||||
|
||||
@ -154,16 +154,16 @@ Concept: nova-manage
|
||||
--------------------
|
||||
|
||||
The nova-manage command is used to perform many essential functions for
|
||||
administration and ongoing maintenance of nova, such as user creation,
|
||||
administration and ongoing maintenance of Nova, such as user creation,
|
||||
vpn management, and much more.
|
||||
|
||||
See doc:`nova.manage` in the Administration Guide for more details.
|
||||
See :doc:`nova.manage` in the Administration Guide for more details.
|
||||
|
||||
|
||||
Concept: Flags
|
||||
--------------
|
||||
|
||||
Nova uses python-gflags for a distributed command line system, and the flags can either be set when running a command at the command line or within flag files. When you install Nova packages, each nova service gets its own flag file. For example, nova-network.conf is used for configuring the nova-network service, and so forth.
|
||||
Nova uses python-gflags for a distributed command line system, and the flags can either be set when running a command at the command line or within flag files. When you install Nova packages, each Nova service gets its own flag file. For example, nova-network.conf is used for configuring the nova-network service, and so forth.
|
||||
|
||||
|
||||
Concept: Plugins
|
||||
@ -181,7 +181,7 @@ Concept: Plugins
|
||||
Concept: IPC/RPC
|
||||
----------------
|
||||
|
||||
Nova utilizes the RabbitMQ implementation of the AMQP messaging standard for performing communication between the various nova services. This message queuing service is used for both local and remote communication because Nova is designed so that there is no requirement that any of the services exist on the same physical machine. RabbitMQ in particular is very robust and provides the efficiency and reliability that Nova needs. More information about RabbitMQ can be found at http://www.rabbitmq.com/.
|
||||
Nova utilizes the RabbitMQ implementation of the AMQP messaging standard for performing communication between the various Nova services. This message queuing service is used for both local and remote communication because Nova is designed so that there is no requirement that any of the services exist on the same physical machine. RabbitMQ in particular is very robust and provides the efficiency and reliability that Nova needs. More information about RabbitMQ can be found at http://www.rabbitmq.com/.
|
||||
|
||||
Concept: Fakes
|
||||
--------------
|
||||
|
||||
@ -59,38 +59,21 @@ different configurations (though for more complex setups you should see
|
||||
* 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
|
||||
* 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
|
||||
-----
|
||||
|
||||
Loading…
Reference in New Issue
Block a user