Merge from trunk

16 files changed, 404 insertions, 187 deletions

diff --git a/doc/source/devref/cloudpipe.rst b/doc/source/devref/cloudpipe.rst
index 4f5d91e28..15d3160b7 100644
--- a/doc/source/devref/cloudpipe.rst
+++ b/doc/source/devref/cloudpipe.rst
@@ -38,6 +38,52 @@ 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).
 
 
+Creating a Cloudpipe Image
+--------------------------
+
+Making a cloudpipe image is relatively easy.
+
+# install openvpn on a base ubuntu image.
+# set up a server.conf.template in /etc/openvpn/
+
+.. literalinclude:: server.conf.template
+   :language: bash
+   :linenos:
+
+# set up.sh in /etc/openvpn/
+
+.. literalinclude:: up.sh
+   :language: bash
+   :linenos:
+
+# set down.sh in /etc/openvpn/
+
+.. literalinclude:: down.sh
+   :language: bash
+   :linenos:
+
+# download and run the payload on boot from /etc/rc.local
+
+.. literalinclude:: rc.local
+   :language: bash
+   :linenos:
+
+# setup /etc/network/interfaces
+
+.. literalinclude:: interfaces
+   :language: bash
+   :linenos:
+
+# register the image and set the image id in your flagfile::
+
+    --vpn_image_id=ami-xxxxxxxx
+
+# you should set a few other flags to make vpns work properly::
+
+    --use_project_ca
+    --cnt_vpn_clients=5
+
+
 Cloudpipe Launch
 ----------------
 
@@ -63,6 +109,31 @@ 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 userdata for cloudpipe isn't currently updated when certs are revoked, so it is necessary to restart the cloudpipe instance if a user's credentials are revoked.
+
+
+Restarting Cloudpipe VPN
+------------------------
+
+You can reboot a cloudpipe vpn through the api if something goes wrong (using euca-reboot-instances for example), but if you generate a new crl, you will have to terminate it and start it again using nova-manage vpn run.  The cloudpipe instance always gets the first ip in the subnet and it can take up to 10 minutes for the ip to be recovered.  If you try to start the new vpn instance too soon, the instance will fail to start because of a NoMoreAddresses error.  If you can't wait 10 minutes, you can manually update the ip with something like the following (use the right ip for the project)::
+
+    euca-terminate-instances <instance_id>
+    mysql nova -e "update fixed_ips set allocated=0, leased=0, instance_id=NULL where fixed_ip='10.0.0.2'"
+
+You also will need to terminate the dnsmasq running for the user (make sure you use the right pid file)::
+
+    sudo kill `cat /var/lib/nova/br100.pid`
+
+Now you should be able to re-run the vpn::
+
+    nova-manage vpn run <project_id>
+
+
+Logging into Cloudpipe VPN
+--------------------------
+
+The keypair that was used to launch the cloudpipe instance should be in the keys/<project_id> folder.  You can use this key to log into the cloudpipe instance for debugging purposes.
+
 
 The :mod:`nova.cloudpipe.pipelib` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/source/devref/down.sh b/doc/source/devref/down.sh
new file mode 100644
index 000000000..5c1888870
--- /dev/null
+++ b/doc/source/devref/down.sh
@@ -0,0 +1,7 @@
+#!/bin/sh
+
+BR=$1
+DEV=$2
+
+/usr/sbin/brctl delif $BR $DEV
+/sbin/ifconfig $DEV down
diff --git a/doc/source/devref/interfaces b/doc/source/devref/interfaces
new file mode 100644
index 000000000..b7116aeb7
--- /dev/null
+++ b/doc/source/devref/interfaces
@@ -0,0 +1,17 @@
+# This file describes the network interfaces available on your system
+# and how to activate them. For more information, see interfaces(5).
+
+# The loopback network interface
+auto lo
+iface lo inet loopback
+
+# The primary network interface
+auto eth0
+iface eth0 inet manual
+  up ifconfig $IFACE 0.0.0.0 up
+  down ifconfig $IFACE down
+
+auto br0
+iface br0 inet dhcp
+  bridge_ports eth0
+
diff --git a/doc/source/devref/rc.local b/doc/source/devref/rc.local
new file mode 100644
index 000000000..d1ccf0cbc
--- /dev/null
+++ b/doc/source/devref/rc.local
@@ -0,0 +1,36 @@
+#!/bin/sh -e
+#
+# rc.local
+#
+# This script is executed at the end of each multiuser runlevel.
+# Make sure that the script will "exit 0" on success or any other
+# value on error.
+#
+# In order to enable or disable this script just change the execution
+# bits.
+#
+# By default this script does nothing.
+####### These lines go at the end of /etc/rc.local #######
+. /lib/lsb/init-functions
+
+echo Downloading payload from userdata
+wget http://169.254.169.254/latest/user-data -O /tmp/payload.b64
+echo Decrypting base64 payload
+openssl enc -d -base64 -in /tmp/payload.b64 -out /tmp/payload.zip
+
+mkdir -p /tmp/payload
+echo Unzipping payload file
+unzip -o /tmp/payload.zip -d /tmp/payload/
+
+# if the autorun.sh script exists, run it
+if [ -e /tmp/payload/autorun.sh ]; then
+  echo Running autorun.sh
+  cd /tmp/payload
+  sh /tmp/payload/autorun.sh
+
+else
+  echo rc.local : No autorun script to run
+fi
+
+
+exit 0
diff --git a/doc/source/devref/server.conf.template b/doc/source/devref/server.conf.template
new file mode 100644
index 000000000..feee3185b
--- /dev/null
+++ b/doc/source/devref/server.conf.template
@@ -0,0 +1,34 @@
+port 1194
+proto udp
+dev tap0
+up "/etc/openvpn/up.sh br0"
+down "/etc/openvpn/down.sh br0"
+
+persist-key
+persist-tun
+
+ca ca.crt
+cert server.crt
+key server.key  # This file should be kept secret
+
+dh dh1024.pem
+ifconfig-pool-persist ipp.txt
+
+server-bridge VPN_IP DHCP_SUBNET DHCP_LOWER DHCP_UPPER
+
+client-to-client
+keepalive 10 120
+comp-lzo
+
+max-clients 1
+
+user nobody
+group nogroup
+
+persist-key
+persist-tun
+
+status openvpn-status.log
+
+verb 3
+mute 20
\ No newline at end of file
diff --git a/doc/source/devref/up.sh b/doc/source/devref/up.sh
new file mode 100644
index 000000000..073a58e15
--- /dev/null
+++ b/doc/source/devref/up.sh
@@ -0,0 +1,7 @@
+#!/bin/sh
+
+BR=$1
+DEV=$2
+MTU=$3
+/sbin/ifconfig $DEV mtu $MTU promisc up
+/usr/sbin/brctl addif $BR $DEV
diff --git a/doc/source/devref/zone.rst b/doc/source/devref/zone.rst
new file mode 100644
index 000000000..3dd9d37d3
--- /dev/null
+++ b/doc/source/devref/zone.rst
@@ -0,0 +1,127 @@
+..
+      Copyright 2010-2011 OpenStack LLC 
+      All Rights Reserved.
+
+      Licensed under the Apache License, Version 2.0 (the "License"); you may
+      not use this file except in compliance with the License. You may obtain
+      a copy of the License at
+
+          http://www.apache.org/licenses/LICENSE-2.0
+
+      Unless required by applicable law or agreed to in writing, software
+      distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+      WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+      License for the specific language governing permissions and limitations
+      under the License.
+
+Zones
+=====
+
+A Nova deployment is called a Zone. At the very least a Zone requires an API node, a Scheduler node, a database and RabbitMQ. Pushed further a Zone may contain many API nodes, many Scheduler, Volume, Network and Compute nodes as well as a cluster of databases and RabbitMQ servers. A Zone allows you to partition your deployments into logical groups for load balancing and instance distribution.
+
+The idea behind Zones is, if a particular deployment is not capable of servicing a particular request, the request may be forwarded to (child) Zones for possible processing. Zones may be nested in a tree fashion. 
+
+Zones only know about their immediate children, they do not know about their parent Zones and may in fact have more than one parent. Likewise, a Zone's children may themselves have child Zones. 
+
+Zones share nothing. They communicate via the public OpenStack API only. No database, queue, user or project definition is shared between Zones. 
+
+
+Capabilities
+------------
+Routing between Zones is based on the Capabilities of that Zone. Capabilities are nothing more than key/value pairs. Values are multi-value, with each value separated with a semicolon (`;`). When expressed as a string they take the form:
+
+::
+
+  key=value;value;value, key=value;value;value
+
+Zones have Capabilities which are general to the Zone and are set via `--zone-capabilities` flag. Zones also have dynamic per-service Capabilities. Services derived from `nova.manager.SchedulerDependentManager` (such as Compute, Volume and Network) can set these capabilities by calling the `update_service_capabilities()` method on their `Manager` base class. These capabilities will be periodically sent to the Scheduler service automatically. The rate at which these updates are sent is controlled by the `--periodic_interval` flag.
+
+Flow within a Zone
+------------------
+The brunt of the work within a Zone is done in the Scheduler Service. The Scheduler is responsible for:
+- collecting capability messages from the Compute, Volume and Network nodes,
+- polling the child Zones for their status and
+- providing data to the Distributed Scheduler for performing load balancing calculations
+
+Inter-service communication within a Zone is done with RabbitMQ. Each class of Service (Compute, Volume and Network) has both a named message exchange (particular to that host) and a general message exchange (particular to that class of service). Messages sent to these exchanges are picked off in round-robin fashion. Zones introduce a new fan-out exchange per service. Messages sent to the fan-out exchange are picked up by all services of a particular class. This fan-out exchange is used by the Scheduler services to receive capability messages from the Compute, Volume and Network nodes.
+
+These capability messages are received by the Scheduler services and stored in the `ZoneManager` object. The SchedulerManager object has a reference to the `ZoneManager` it can use for load balancing.
+
+The `ZoneManager` also polls the child Zones periodically to gather their capabilities to aid in decision making. This is done via the OpenStack API `/v1.0/zones/info` REST call. This also captures the name of each child Zone. The Zone name is set via the `--zone-name` flag (and defaults to "nova"). 
+
+Zone administrative functions
+-----------------------------
+Zone administrative operations are usually done using python-novaclient_
+
+.. _python-novaclient: https://github.com/rackspace/python-novaclient
+
+In order to use the Zone operations, be sure to enable administrator operations in OpenStack API by setting the `--allow_admin_api=true` flag.
+
+Finally you need to enable Zone Forwarding. This will be used by the Distributed Scheduler initiative currently underway. Set `--enable_zone_routing=true` to enable this feature.
+
+Find out about this Zone
+------------------------
+In any Zone you can find the Zone's name and capabilities with the ``nova zone-info`` command.
+
+::
+
+  alice@novadev:~$ nova zone-info
+  +-----------------+---------------+
+  |     Property    |     Value     |
+  +-----------------+---------------+
+  | compute_cpu     | 0.7,0.7       |
+  | compute_disk    | 123000,123000 |
+  | compute_network | 800,800       |
+  | hypervisor      | xenserver     |
+  | name            | nova          |
+  | network_cpu     | 0.7,0.7       |
+  | network_disk    | 123000,123000 |
+  | network_network | 800,800       |
+  | os              | linux         |
+  +-----------------+---------------+
+
+This equates to a GET operation on `.../zones/info`. If you have no child Zones defined you'll usually only get back the default `name`, `hypervisor` and `os` capabilities. Otherwise you'll get back a tuple of min, max values for each capabilities of all the hosts of all the services running in the child zone. These take the `<service>_<capability> = <min>,<max>` format.
+
+Adding a child Zone
+-------------------
+Any Zone can be a parent Zone. Children are associated to a Zone. The Zone where this command originates from is known as the Parent Zone. Routing is only ever conducted from a Zone to its children, never the other direction. From a parent zone you can add a child zone with the following command:
+
+::
+
+  nova zone-add <child zone api url> <username> <nova api key>
+
+You can get the `child zone api url`, `nova api key` and `username` from the `novarc` file in the child zone. For example:
+
+::
+
+  export NOVA_API_KEY="3bd1af06-6435-4e23-a827-413b2eb86934"
+  export NOVA_USERNAME="alice"
+  export NOVA_URL="http://192.168.2.120:8774/v1.0/"
+
+
+This equates to a POST operation to `.../zones/` to add a new zone. No connection attempt to the child zone is done when this command. It only puts an entry in the db at this point. After about 30 seconds the `ZoneManager` in the Scheduler services will attempt to talk to the child zone and get its information. 
+
+Getting a list of child Zones
+-----------------------------
+
+::
+
+  nova zone-list
+
+  alice@novadev:~$ nova zone-list
+  +----+-------+-----------+--------------------------------------------+---------------------------------+
+  | ID |  Name | Is Active |                Capabilities                |             API URL             |
+  +----+-------+-----------+--------------------------------------------+---------------------------------+
+  | 2  | zone1 | True      | hypervisor=xenserver;kvm, os=linux;windows | http://192.168.2.108:8774/v1.0/ |
+  | 3  | zone2 | True      | hypervisor=xenserver;kvm, os=linux;windows | http://192.168.2.115:8774/v1.0/ |
+  +----+-------+-----------+--------------------------------------------+---------------------------------+
+
+This equates to a GET operation to `.../zones`.
+
+Removing a child Zone
+---------------------
+::
+
+  nova zone-delete <N>
+
+This equates to a DELETE call to `.../zones/N`. The Zone with ID=N will be removed. This will only remove the zone entry from the current (parent) Zone, no child Zones are affected. Removing a Child Zone doesn't affect any other part of the hierarchy.
diff --git a/doc/source/man/novamanage.rst b/doc/source/man/novamanage.rst
index 1d8446f08..9c54f3608 100644
--- a/doc/source/man/novamanage.rst
+++ b/doc/source/man/novamanage.rst
@@ -240,6 +240,16 @@ Nova Images
 
     Converts all images in directory from the old (Bexar) format to the new format.
 
+Nova VM
+~~~~~~~~~~~
+
+``nova-manage vm list [host]``
+    Show a list of all instances. Accepts optional hostname (to show only instances on specific host).
+
+``nova-manage live-migration <ec2_id> <destination host name>``
+    Live migrate instance from current host to destination host. Requires instance id (which comes from euca-describe-instance) and destination host name (which can be found from nova-manage service list).
+
+
 FILES
 ========
 
diff --git a/doc/source/runnova/flags.rst b/doc/source/runnova/flags.rst
index 1bfa022d9..3d16e1303 100644
--- a/doc/source/runnova/flags.rst
+++ b/doc/source/runnova/flags.rst
@@ -20,174 +20,4 @@ Flags and Flagfiles
 
 Nova uses a configuration file containing flags located in /etc/nova/nova.conf. You can get the most recent listing of avaialble flags by running nova-(servicename) --help, for example, nova-api --help. 
 
-Here's a list of available flags and their default settings. 
-
-  --ajax_console_proxy_port: port that ajax_console_proxy binds
-    (default: '8000')
-  --ajax_console_proxy_topic: the topic ajax proxy nodes listen on
-    (default: 'ajax_proxy')
-  --ajax_console_proxy_url: location of ajax console proxy, in the form
-    "http://127.0.0.1:8000"
-    (default: 'http://127.0.0.1:8000')
-  --auth_token_ttl: Seconds for auth tokens to linger
-    (default: '3600')
-    (an integer)
-  --aws_access_key_id: AWS Access ID
-    (default: 'admin')
-  --aws_secret_access_key: AWS Access Key
-    (default: 'admin')
-  --compute_manager: Manager for compute
-    (default: 'nova.compute.manager.ComputeManager')
-  --compute_topic: the topic compute nodes listen on
-    (default: 'compute')
-  --connection_type: libvirt, xenapi or fake
-    (default: 'libvirt')
-  --console_manager: Manager for console proxy
-    (default: 'nova.console.manager.ConsoleProxyManager')
-  --console_topic: the topic console proxy nodes listen on
-    (default: 'console')
-  --control_exchange: the main exchange to connect to
-    (default: 'nova')
-  --db_backend: The backend to use for db
-    (default: 'sqlalchemy')
-  --default_image: default image to use, testing only
-    (default: 'ami-11111')
-  --default_instance_type: default instance type to use, testing only
-    (default: 'm1.small')
-  --default_log_levels: list of logger=LEVEL pairs
-    (default: 'amqplib=WARN,sqlalchemy=WARN,eventlet.wsgi.server=WARN')
-    (a comma separated list)
-  --default_project: default project for openstack
-    (default: 'openstack')
-  --ec2_dmz_host: internal ip of api server
-    (default: '$my_ip')
-  --ec2_host: ip of api server
-    (default: '$my_ip')
-  --ec2_path: suffix for ec2
-    (default: '/services/Cloud')
-  --ec2_port: cloud controller port
-    (default: '8773')
-    (an integer)
-  --ec2_scheme: prefix for ec2
-    (default: 'http')
-  --[no]enable_new_services: Services to be added to the available pool on
-    create
-    (default: 'true')
-  --[no]fake_network: should we use fake network devices and addresses
-    (default: 'false')
-  --[no]fake_rabbit: use a fake rabbit
-    (default: 'false')
-  --glance_host: glance host
-    (default: '$my_ip')
-  --glance_port: glance port
-    (default: '9292')
-    (an integer)
-  -?,--[no]help: show this help
-  --[no]helpshort: show usage only for this module
-  --[no]helpxml: like --help, but generates XML output
-  --host: name of this node
-    (default: 'osdemo03')
-  --image_service: The service to use for retrieving and searching for images.
-    (default: 'nova.image.s3.S3ImageService')
-  --instance_name_template: Template string to be used to generate instance
-    names
-    (default: 'instance-%08x')
-  --logfile: output to named file
-  --logging_context_format_string: format string to use for log messages with
-    context
-    (default: '%(asctime)s %(levelname)s %(name)s [%(request_id)s %(user)s
-    %(project)s] %(message)s')
-  --logging_debug_format_suffix: data to append to log format when level is
-    DEBUG
-    (default: 'from %(processName)s (pid=%(process)d) %(funcName)s
-    %(pathname)s:%(lineno)d')
-  --logging_default_format_string: format string to use for log messages without
-    context
-    (default: '%(asctime)s %(levelname)s %(name)s [-] %(message)s')
-  --logging_exception_prefix: prefix each line of exception output with this
-    format
-    (default: '(%(name)s): TRACE: ')
-  --my_ip: host ip address
-    (default: '184.106.73.68')
-  --network_manager: Manager for network
-    (default: 'nova.network.manager.VlanManager')
-  --network_topic: the topic network nodes listen on
-    (default: 'network')
-  --node_availability_zone: availability zone of this node
-    (default: 'nova')
-  --null_kernel: kernel image that indicates not to use a kernel, but to use a
-    raw disk image instead
-    (default: 'nokernel')
-  --osapi_host: ip of api server
-    (default: '$my_ip')
-  --osapi_path: suffix for openstack
-    (default: '/v1.0/')
-  --osapi_port: OpenStack API port
-    (default: '8774')
-    (an integer)
-  --osapi_scheme: prefix for openstack
-    (default: 'http')
-  --periodic_interval: seconds between running periodic tasks
-    (default: '60')
-    (a positive integer)
-  --pidfile: pidfile to use for this service
-  --rabbit_host: rabbit host
-    (default: 'localhost')
-  --rabbit_max_retries: rabbit connection attempts
-    (default: '12')
-    (an integer)
-  --rabbit_password: rabbit password
-    (default: 'guest')
-  --rabbit_port: rabbit port
-    (default: '5672')
-    (an integer)
-  --rabbit_retry_interval: rabbit connection retry interval
-    (default: '10')
-    (an integer)
-  --rabbit_userid: rabbit userid
-    (default: 'guest')
-  --rabbit_virtual_host: rabbit virtual host
-    (default: '/')
-  --region_list: list of region=fqdn pairs separated by commas
-    (default: '')
-    (a comma separated list)
-  --report_interval: seconds between nodes reporting state to datastore
-    (default: '10')
-    (a positive integer)
-  --s3_dmz: s3 dmz ip (for instances)
-    (default: '$my_ip')
-  --s3_host: s3 host (for infrastructure)
-    (default: '$my_ip')
-  --s3_port: s3 port
-    (default: '3333')
-    (an integer)
-  --scheduler_manager: Manager for scheduler
-    (default: 'nova.scheduler.manager.SchedulerManager')
-  --scheduler_topic: the topic scheduler nodes listen on
-    (default: 'scheduler')
-  --sql_connection: connection string for sql database
-    (default: 'sqlite:///$state_path/nova.sqlite')
-  --sql_idle_timeout: timeout for idle sql database connections
-    (default: '3600')
-  --sql_max_retries: sql connection attempts
-    (default: '12')
-    (an integer)
-  --sql_retry_interval: sql connection retry interval
-    (default: '10')
-    (an integer)
-  --state_path: Top-level directory for maintaining nova's state
-    (default: '/usr/lib/pymodules/python2.6/nova/../')
-  --[no]use_syslog: output to syslog
-    (default: 'false')
-  --[no]verbose: show debug output
-    (default: 'false')
-  --volume_manager: Manager for volume
-    (default: 'nova.volume.manager.VolumeManager')
-  --volume_name_template: Template string to be used to generate instance names
-    (default: 'volume-%08x')
-  --volume_topic: the topic volume nodes listen on
-    (default: 'volume')
-  --vpn_image_id: AMI for cloudpipe vpn server
-    (default: 'ami-cloudpipe')
-  --vpn_key_suffix: Suffix to add to project name for vpn key and secgroups
-    (default: '-vpn')
\ No newline at end of file
+The OpenStack wiki has a page with the flags listed by their purpose and use at http://wiki.openstack.org/FlagsGrouping.
\ No newline at end of file
diff --git a/doc/source/runnova/index.rst b/doc/source/runnova/index.rst
index 283d268ce..769bbec84 100644
--- a/doc/source/runnova/index.rst
+++ b/doc/source/runnova/index.rst
@@ -18,7 +18,7 @@
 Running Nova
 ============
 
-This guide describes the basics of running and managing Nova. For more administrator's documentation, refer to `docs.openstack.org <http://docs.openstack.org>`_.
+This guide describes the basics of running and managing Nova. This site is intended to provide developer documentation. For more administrator's documentation, refer to `docs.openstack.org <http://docs.openstack.org>`_.
 
 Running the Cloud
 -----------------
@@ -60,7 +60,7 @@ For background on the core objects referenced in this section, see :doc:`../obje
 Deployment
 ----------
 
-For a starting multi-node architecture, you would start with two nodes - a cloud controller node and a compute node. The cloud controller node contains the nova- services plus the Nova database. The compute node installs all the nova-services but then refers to the database installation, which is hosted by the cloud controller node. Ensure that the nova.conf file is identical on each node. If you find performance issues not related to database reads or writes, but due to the messaging queue backing up, you could add additional messaging services (rabbitmq). For instructions on multi-server installations, refer to `Installing and Configuring OpenStack Compute <http://docs.openstack.org/openstack-compute/admin/content/ch03.html>`_.
+For a starting multi-node architecture, you would start with two nodes - a cloud controller node and a compute node. The cloud controller node contains the nova- services plus the Nova database. The compute node installs all the nova-services but then refers to the database installation, which is hosted by the cloud controller node. Ensure that the nova.conf file is identical on each node. If you find performance issues not related to database reads or writes, but due to the messaging queue backing up, you could add additional messaging services (rabbitmq). For instructions on multi-server installations, refer to `Installing and Configuring OpenStack Compute <http://docs.openstack.org/>`_.
 
 
 .. toctree::
diff --git a/doc/source/runnova/managing.images.rst b/doc/source/runnova/managing.images.rst
index c5d93a6e8..a2e618602 100644
--- a/doc/source/runnova/managing.images.rst
+++ b/doc/source/runnova/managing.images.rst
@@ -18,4 +18,9 @@
 Managing Images
 ===============
 
-.. todo:: Put info on managing images  here!
+With Nova, you can manage images either using the built-in object store or using Glance, a related OpenStack project. Glance is a server that provides the following services:
+
+ * Ability to store and retrieve virtual machine images
+ * Ability to store and retrieve metadata about these virtual machine images
+
+Refer to http://glance.openstack.org for additional details. 
\ No newline at end of file
diff --git a/doc/source/runnova/managing.instance.types.rst b/doc/source/runnova/managing.instance.types.rst
index 746077716..a575e16b7 100644
--- a/doc/source/runnova/managing.instance.types.rst
+++ b/doc/source/runnova/managing.instance.types.rst
@@ -16,6 +16,8 @@
 Managing Instance Types and Flavors
 ===================================
 
+You can manage instance types and instance flavors using the nova-manage command-line interface coupled with the instance_type subcommand for nova-manage. 
+
 What are Instance Types or Flavors ?
 ------------------------------------
 
diff --git a/doc/source/runnova/managingsecurity.rst b/doc/source/runnova/managingsecurity.rst
index 7893925e7..85329ed4a 100644
--- a/doc/source/runnova/managingsecurity.rst
+++ b/doc/source/runnova/managingsecurity.rst
@@ -18,8 +18,6 @@
 Security Considerations
 =======================
 
-.. todo:: This doc is vague and just high-level right now. Describe architecture that enables security.
-
 The goal of securing a cloud computing system involves both protecting the instances, data on the instances, and
 ensuring users are authenticated for actions and that borders are understood by the users and the system.
 Protecting the system from intrusion or attack involves authentication, network protections,  and
diff --git a/doc/source/runnova/network.vlan.rst b/doc/source/runnova/network.vlan.rst
index c06ce8e8b..df19c7a80 100644
--- a/doc/source/runnova/network.vlan.rst
+++ b/doc/source/runnova/network.vlan.rst
@@ -36,9 +36,7 @@ In this mode, each project gets its own VLAN, Linux networking bridge, and subne
    
 While network traffic between VM instances belonging to the same VLAN is always open, Nova can enforce isolation of network traffic between different projects by enforcing one VLAN per project. 
 
-In addition, the network administrator can specify a pool of public IP addresses that users may allocate and then assign to VMs, either at boot or dynamically at run-time. This capability is similar to Amazon's 'elastic IPs'. A public IP address may be associated with a running instances, allowing the VM instance to be accessed from the public network. The public IP addresses are accessible from the network host and NATed to the private IP address of the project. 
-
-.. todo:: Describe how a public IP address could be associated with a project (a VLAN)
+In addition, the network administrator can specify a pool of public IP addresses that users may allocate and then assign to VMs, either at boot or dynamically at run-time. This capability is similar to Amazon's 'elastic IPs'. A public IP address may be associated with a running instances, allowing the VM instance to be accessed from the public network. The public IP addresses are accessible from the network host and NATed to the private IP address of the project. A public IP address could be associated with a project using the euca-allocate-address commands. 
 
 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>`.
 
@@ -176,4 +174,3 @@ Setup
   * project network size
   * DMZ network
 
-.. todo:: need specific Nova configuration added
diff --git a/doc/source/runnova/nova.manage.rst b/doc/source/runnova/nova.manage.rst
index 0636e5752..af82b6a4f 100644
--- a/doc/source/runnova/nova.manage.rst
+++ b/doc/source/runnova/nova.manage.rst
@@ -83,13 +83,13 @@ Nova User
 Nova Project
 ~~~~~~~~~~~~
 
-``nova-manage project add <projectname>``
+``nova-manage project add <projectname> <username>``
 
-    Add a nova project with the name <projectname> to the database.
+    Add a nova project with the name <projectname> to the database that will be administered by the named user.
 
-``nova-manage project create <projectname>``
+``nova-manage project create <projectname> <projectmanager>``
 
-    Create a new nova project with the name <projectname> (you still need to do nova-manage project add <projectname> to add it to the database).
+    Create a new nova project with the name <projectname> (you still need to do nova-manage project add <projectname> to add it to the database). The <projectmanager> username is the administrator of the project.
 
 ``nova-manage project delete <projectname>``
 
@@ -111,9 +111,9 @@ Nova Project
 
     Deletes the project with the name <projectname>.
 
-``nova-manage project zipfile``
+``nova-manage project zipfile <projectname> <username> <directory for credentials>``
 
-    Compresses all related files for a created project into a zip file nova.zip.
+    Compresses all related files for a created project into a named zip file such as nova.zip.
 
 Nova Role
 ~~~~~~~~~
@@ -226,7 +226,7 @@ Concept: Plugins
 Concept: IPC/RPC
 ----------------
 
-Rabbit!
+Rabbit is the main messaging queue, used for all communication between Nova components and it also does the remote procedure calls and inter-process communication. 
 
 
 Concept: Fakes
diff --git a/doc/source/runnova/vncconsole.rst b/doc/source/runnova/vncconsole.rst
new file mode 100644
index 000000000..c1fe9be39
--- /dev/null
+++ b/doc/source/runnova/vncconsole.rst
@@ -0,0 +1,76 @@
+..
+      Copyright 2010-2011 United States Government as represented by the
+      Administrator of the National Aeronautics and Space Administration.
+      All Rights Reserved.
+
+      Licensed under the Apache License, Version 2.0 (the "License"); you may
+      not use this file except in compliance with the License. You may obtain
+      a copy of the License at
+
+          http://www.apache.org/licenses/LICENSE-2.0
+
+      Unless required by applicable law or agreed to in writing, software
+      distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+      WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+      License for the specific language governing permissions and limitations
+      under the License.
+
+Getting Started with the VNC Proxy
+==================================
+
+The VNC Proxy is an OpenStack component that allows users of Nova to access
+their instances through a websocket enabled browser (like Google Chrome).
+
+A VNC Connection works like so:
+
+* User connects over an api and gets a url like http://ip:port/?token=xyz
+* User pastes url in browser
+* Browser connects to VNC Proxy though a websocket enabled client like noVNC
+* VNC Proxy authorizes users token, maps the token to a host and port of an
+  instance's VNC server
+* VNC Proxy initiates connection to VNC server, and continues proxying until
+  the session ends
+
+
+Configuring the VNC Proxy
+-------------------------
+nova-vncproxy requires a websocket enabled html client to work properly.  At
+this time, the only tested client is a slightly modified fork of noVNC, which
+you can at find http://github.com/openstack/noVNC.git
+
+.. todo:: add instruction for installing from package
+
+noVNC must be in the location specified by --vncproxy_wwwroot, which defaults
+to /var/lib/nova/noVNC.  nova-vncproxy will fail to launch until this code
+is properly installed.
+
+By default, nova-vncproxy binds 0.0.0.0:6080.  This can be configured with:
+
+* --vncproxy_port=[port]
+* --vncproxy_host=[host]
+
+
+Enabling VNC Consoles in Nova
+-----------------------------
+At the moment, VNC support is supported only when using libvirt.  To enable VNC
+Console, configure the following flags:
+
+* --vnc_console_proxy_url=http://[proxy_host]:[proxy_port] - proxy_port
+  defaults to 6080.  This url must point to nova-vncproxy
+* --vnc_enabled=[True|False] - defaults to True. If this flag is not set your
+  instances will launch without vnc support.
+
+
+Getting an instance's VNC Console
+---------------------------------
+You can access an instance's VNC Console url in the following methods:
+
+* Using the direct api:
+  eg: 'stack --user=admin --project=admin compute get_vnc_console instance_id=1'
+* Support for Dashboard, and the Openstack API will be forthcoming
+
+
+Accessing VNC Consoles without a web browser
+--------------------------------------------
+At the moment, VNC Consoles are only supported through the web browser, but
+more general VNC support is in the works.