removes the nova-volume code from nova

This removes the majority of the nova-volume code from the codebase.
It updates relevent config options to default to cinder. It updates a
number of existing tests that were depending on code that was removed.

A few things still need to be removed:

 * volume/driver.py & volume/iscsi.py
   These files are used by the libvirt volume driver tests. These
   tests should be updated to mock the relevant calls.

 * scheduler/simple.py & scheduler/multi.py
   These files should no longer be necessary so they can be removed
   in a subsequent patch

 * exception.py cleanup
   Once the above files are removed there are a number of unused
   exceptions which can be removed

 * database calls and database tables
   The database calls have not been removed and the tables have not
   been dropped. This can be done in a separate migration

 * additional config options and nova.conf.sample
   There may be a few extra config options that can be removed and the
   conf sample can be regenerated

Implements bp delete-nova-volume

Change-Id: I0b540e54dbabd26901a7530035a38583bb521fda

10 files changed, 9 insertions, 324 deletions

diff --git a/doc/source/conf.py b/doc/source/conf.py
index 7f77cc5d3..b52bcad0d 100644
--- a/doc/source/conf.py
+++ b/doc/source/conf.py
@@ -127,8 +127,6 @@ man_pages = [
      [u'OpenStack'], 1),
     ('man/nova-api-os-compute', 'nova-api-os-compute',
      u'Cloud controller fabric', [u'OpenStack'], 1),
-    ('man/nova-api-os-volume', 'nova-api-os-volume',
-      u'Cloud controller fabric', [u'OpenStack'], 1),
     ('man/nova-api', 'nova-api', u'Cloud controller fabric',
      [u'OpenStack'], 1),
     ('man/nova-cert', 'nova-cert', u'Cloud controller fabric',
@@ -155,10 +153,6 @@ man_pages = [
      [u'OpenStack'], 1),
     ('man/nova-scheduler', 'nova-scheduler', u'Cloud controller fabric',
      [u'OpenStack'], 1),
-    ('man/nova-volume-usage-audit', 'nova-volume-usage-audit', u'Cloud controller fabric',
-     [u'OpenStack'], 1),
-    ('man/nova-volume', 'nova-volume', u'Cloud controller fabric',
-     [u'OpenStack'], 1),
     ('man/nova-xvpvncproxy', 'nova-xvpvncproxy', u'Cloud controller fabric',
      [u'OpenStack'], 1)
 ]
diff --git a/doc/source/devref/architecture.rst b/doc/source/devref/architecture.rst
index db5947a3e..3c4a5ca48 100644
--- a/doc/source/devref/architecture.rst
+++ b/doc/source/devref/architecture.rst
@@ -33,8 +33,8 @@ Below you will find a helpful explanation of the different components.
                   [ Auth Manager ] ---
                           |           \- ( DB )
                           |
-                          |       [ scheduler ] - [ volume ]  - ( iSCSI )
-                          |                /
+                          |
+                          |
   [ Web Dashboard ] -> [ api ] -- < AMQP > ------ [ network ] - ( Flat/Vlan )
                           |                \
                        < HTTP >   [ scheduler ] - [ compute ] - ( libvirt/xen )
@@ -46,7 +46,6 @@ Below you will find a helpful explanation of the different components.
 * api: component that receives http requests, converts commands and communicates with other components via the queue or http (in the case of objectstore)
 * Auth Manager: component responsible for users/projects/and roles.  Can backend to DB or LDAP.  This is not a separate binary, but rather a python class that is used by most components in the system.
 * objectstore: http server that replicates s3 api and allows storage and retrieval of images
-* scheduler: decides which host gets each vm and volume
-* volume: manages dynamically attachable block devices.
+* scheduler: decides which host gets each vm
 * network: manages ip forwarding, bridges, and vlans
 * compute: manages communication with hypervisor and virtual machines.
diff --git a/doc/source/devref/index.rst b/doc/source/devref/index.rst
index a04bc83ca..239848c62 100644
--- a/doc/source/devref/index.rst
+++ b/doc/source/devref/index.rst
@@ -67,8 +67,6 @@ Module Reference
 
    services
    database
-   volume
-   xensmvolume
    compute
    network
    api
diff --git a/doc/source/devref/rpc.rst b/doc/source/devref/rpc.rst
index 8ed901a6b..9d97c308a 100644
--- a/doc/source/devref/rpc.rst
+++ b/doc/source/devref/rpc.rst
@@ -30,12 +30,12 @@ Nova uses direct, fanout, and topic-based exchanges. The architecture looks like
 
 ..
 
-Nova implements RPC (both request+response, and one-way, respectively nicknamed 'rpc.call' and 'rpc.cast') over AMQP by providing an adapter class which take cares of marshaling and unmarshaling of messages into function calls. Each Nova service (for example Compute, Volume, etc.) create two queues at the initialization time, one which accepts messages with routing keys 'NODE-TYPE.NODE-ID' (for example compute.hostname) and another, which accepts messages with routing keys as generic 'NODE-TYPE' (for example compute). The former is used specifically when Nova-API needs to redirect commands to a specific node like 'euca-terminate instance'. In this case, only the  compute node whose host's hypervisor is running the virtual machine can kill the instance. The API acts as a consumer when RPC calls are request/response, otherwise is acts as publisher only.
+Nova implements RPC (both request+response, and one-way, respectively nicknamed 'rpc.call' and 'rpc.cast') over AMQP by providing an adapter class which take cares of marshaling and unmarshaling of messages into function calls. Each Nova service (for example Compute, Scheduler, etc.) create two queues at the initialization time, one which accepts messages with routing keys 'NODE-TYPE.NODE-ID' (for example compute.hostname) and another, which accepts messages with routing keys as generic 'NODE-TYPE' (for example compute). The former is used specifically when Nova-API needs to redirect commands to a specific node like 'euca-terminate instance'. In this case, only the  compute node whose host's hypervisor is running the virtual machine can kill the instance. The API acts as a consumer when RPC calls are request/response, otherwise is acts as publisher only.
 
 Nova RPC Mappings
 -----------------
 
-The figure below shows the internals of a message broker node (referred to as a RabbitMQ node in the diagrams) when a single instance is deployed and shared in an OpenStack cloud. Every Nova component connects to the message broker and, depending on its personality (for example a compute node or a network node), may use the queue either as an Invoker (such as API or Scheduler) or a Worker (such as Compute, Volume or Network). Invokers and Workers do not actually exist in the Nova object model, but we are going to use them as an abstraction for sake of clarity. An Invoker is a component that sends messages in the queuing system via two operations: 1) rpc.call and ii) rpc.cast; a Worker is a component that receives messages from the queuing system and reply accordingly to rcp.call operations.
+The figure below shows the internals of a message broker node (referred to as a RabbitMQ node in the diagrams) when a single instance is deployed and shared in an OpenStack cloud. Every Nova component connects to the message broker and, depending on its personality (for example a compute node or a network node), may use the queue either as an Invoker (such as API or Scheduler) or a Worker (such as Compute or Network). Invokers and Workers do not actually exist in the Nova object model, but we are going to use them as an abstraction for sake of clarity. An Invoker is a component that sends messages in the queuing system via two operations: 1) rpc.call and ii) rpc.cast; a Worker is a component that receives messages from the queuing system and reply accordingly to rcp.call operations.
 
 Figure 2 shows the following internal elements:
 
@@ -97,10 +97,8 @@ The figure below shows the status of a RabbitMQ node after Nova components' boot
        2. compute
        3. network.phantom (phantom is hostname)
        4. network
-       5. volume.phantom (phantom is hostname)
-       6. volume
-       7. scheduler.phantom (phantom is hostname)
-       8. scheduler
+       5. scheduler.phantom (phantom is hostname)
+       6. scheduler
 
 .. image:: /images/rpc/state.png
    :width: 60%
diff --git a/doc/source/devref/volume.rst b/doc/source/devref/volume.rst
deleted file mode 100644
index c9e0387ff..000000000
--- a/doc/source/devref/volume.rst
+++ /dev/null
@@ -1,52 +0,0 @@
-..
-      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.
-
-Storage Volumes, Disks
-======================
-
-.. todo:: rework after iSCSI merge (see 'Old Docs') (todd or vish)
-
-
-The :mod:`nova.volume.manager` Module
--------------------------------------
-
-.. automodule:: nova.volume.manager
-    :noindex:
-    :members:
-    :undoc-members:
-    :show-inheritance:
-
-The :mod:`nova.volume.driver` Module
--------------------------------------
-
-.. automodule:: nova.volume.driver
-    :noindex:
-    :members:
-    :undoc-members:
-    :show-inheritance:
-
-Tests
------
-
-The :mod:`volume_unittest` Module
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-.. automodule:: nova.tests.volume_unittest
-    :noindex:
-    :members:
-    :undoc-members:
-    :show-inheritance:
diff --git a/doc/source/devref/xensmvolume.rst b/doc/source/devref/xensmvolume.rst
deleted file mode 100644
index 883cdd931..000000000
--- a/doc/source/devref/xensmvolume.rst
+++ /dev/null
@@ -1,88 +0,0 @@
-Xen Storage Manager Volume Driver
-=================================
-
-The Xen Storage Manager (xensm) driver for Nova-Volume is based on XenAPI Storage Manager. This will not only provide basic storage functionality (like volume creation, and destruction) on a number of different storage back-ends, such as Netapp, NFS, etc. but it will also enable the capability of using more sophisticated storage back-ends for operations like cloning/snapshotting etc. To have an idea of the benefits of using XenAPI SM to provide back-end storage services, the list below shows some of the storage plugins already supported in XenServer/XCP:
-
--   NFS VHD: SR plugin which stores disks as VHD files on a remote NFS filesystem
--   Local VHD on LVM: SR plugin which represents disks as VHD disks on Logical Volumes within a locally-attached Volume Group
--   HBA LUN-per-VDI driver: SR plugin which represents LUNs as VDIs sourced by hardware HBA adapters, e.g. hardware-based iSCSI or FC support
--   NetApp: SR driver for mapping of LUNs to VDIs on a NETAPP server, providing use of fast snapshot and clone features on the filer
--   LVHD over FC: SR plugin which represents disks as VHDs on Logical Volumes within a Volume Group created on an HBA LUN, e.g. hardware-based iSCSI or FC support
--   iSCSI: Base ISCSI SR driver, provides a LUN-per-VDI. Does not support creation of VDIs but accesses existing LUNs on a target.
--   LVHD over iSCSI: SR plugin which represents disks as Logical Volumes within a Volume Group created on an iSCSI LUN
--   EqualLogic: SR driver for mapping of LUNs to VDIs on an EQUALLOGIC array group, providing use of fast snapshot and clone features on the array 
-
-Glossary
-=========
-
-    XenServer: Commercial, supported product from Citrix
-
-    Xen Cloud Platform (XCP): Open-source equivalent of XenServer (and the development project for the toolstack). Everything said about XenServer below applies equally to XCP
-
-    XenAPI: The management API exposed by XenServer and XCP
-
-    xapi: The primary daemon on XenServer and Xen Cloud Platform; the one that exposes the XenAPI 
-
-
-Design
-=======
-
-Definitions
------------
-
-Backend: A term for a particular storage backend. This could be iSCSI, NFS, Netapp etc.
-Backend-config: All the parameters required to connect to a specific backend. For e.g. For NFS, this would be the server, path, etc.
-Flavor: This term is equivalent to volume "types". A user friendly term to specify some notion of quality of service. For example, "gold" might mean that the volumes will use a backend where backups are possible.
-
-A flavor can be associated with multiple backends. The volume scheduler, with the help of the driver, will decide which backend will be used to create a volume of a particular flavor. Currently, the driver uses a simple "first-fit" policy, where the first backend that can successfully create this volume is the one that is used.
-
-Operation
-----------
-
-Using the nova-manage command detailed in the implementation, an admin can add flavors and backends.
-
-One or more nova-volume service instances will be deployed per availability zone. When an instance is started, it will create storage repositories (SRs) to connect to the backends available within that zone. All nova-volume instances within a zone can see all the available backends. These instances are completely symmetric and hence should be able to service any create_volume request within the zone.
-
-
-Commands
-=========
-
-A category called "sm" has been added to nova-manage in the class StorageManagerCommands.
-
-The following actions will be added:
-
--    flavor_list
--    flavor_create
--    flavor_delete
--    backend_list
--    backend_add
--    backend_remove 
-
-Usage:
-------
-
-nova-manage sm flavor_create <label> <description>
-
-nova-manage sm flavor_delete<label>
-
-nova-manage sm backend_add <flavor label> <SR type> [config connection parameters]
-
-Note: SR type and config connection parameters are in keeping with the Xen Command Line Interface. http://support.citrix.com/article/CTX124887
-
-nova-manage sm backend_delete <backend-id>
-
-Examples:
----------
-
-nova-manage sm flavor_create gold "Not all that glitters"
-
-nova-manage sm flavor_delete gold
-
-nova-manage sm backend_add gold nfs name_label=toybox-renuka server=myserver serverpath=/local/scratch/myname
-
-nova-manage sm backend_remove 1
-
-API Changes
-===========
-
-No API changes have been introduced so far. The existing euca-create-volume and euca-delete-volume commands (or equivalent OpenStack API commands) should be used.
diff --git a/doc/source/man/nova-api-os-volume.rst b/doc/source/man/nova-api-os-volume.rst
deleted file mode 100644
index 2d3e009f1..000000000
--- a/doc/source/man/nova-api-os-volume.rst
+++ /dev/null
@@ -1,49 +0,0 @@
-===================
-nova-api-os-volume
-===================
-
--------------------------------------------
-Server for the Nova OpenStack Volume APIs
--------------------------------------------
-
-:Author: openstack@lists.launchpad.net
-:Date:   2012-09-27
-:Copyright: OpenStack LLC
-:Version: 2012.1
-:Manual section: 1
-:Manual group: cloud computing
-
-SYNOPSIS
-========
-
-  nova-api-os-volume [options]
-
-DESCRIPTION
-===========
-
-nova-api-os-volume is a server daemon that serves the Nova OpenStack API
-
-OPTIONS
-=======
-
- **General options**
-
-FILES
-========
-
-* /etc/nova/nova.conf
-* /etc/nova/api-paste.ini
-* /etc/nova/policy.json
-* /etc/nova/rootwrap.conf
-* /etc/nova/rootwrap.d/
-
-SEE ALSO
-========
-
-* `OpenStack Nova <http://nova.openstack.org>`__
-* `OpenStack Nova <http://nova.openstack.org>`__
-
-BUGS
-====
-
-* Nova is sourced in Launchpad so you can view current bugs at `OpenStack Nova <http://nova.openstack.org>`__
diff --git a/doc/source/man/nova-rootwrap.rst b/doc/source/man/nova-rootwrap.rst
index e69af588a..8bc089a35 100644
--- a/doc/source/man/nova-rootwrap.rst
+++ b/doc/source/man/nova-rootwrap.rst
@@ -30,8 +30,8 @@ You also need to let the nova user run nova-rootwrap as root in sudoers:
 nova ALL = (root) NOPASSWD: /usr/bin/nova-rootwrap /etc/nova/rootwrap.conf *
 
 To make allowed commands node-specific, your packaging should only
-install {compute,network,volume}.filters respectively on compute, network
-and volume nodes (i.e. nova-api nodes should not have any of those files
+install {compute,network}.filters respectively on compute and network
+nodes (i.e. nova-api nodes should not have any of those files
 installed).
 
 
diff --git a/doc/source/man/nova-volume-usage-audit.rst b/doc/source/man/nova-volume-usage-audit.rst
deleted file mode 100644
index 628536a79..000000000
--- a/doc/source/man/nova-volume-usage-audit.rst
+++ /dev/null
@@ -1,61 +0,0 @@
-=======================
-nova-volume-usage-audit
-=======================
-
--------------------------------------------
-Generate Usage Notifications for Volumes
--------------------------------------------
-
-:Author: openstack@lists.launchpad.net
-:Date:   2012-09-27
-:Copyright: OpenStack LLC
-:Version: 2012.1
-:Manual section: 1
-:Manual group: cloud computing
-
-SYNOPSIS
-========
-
-  nova-volume-usage-audit  [options]
-
-DESCRIPTION
-===========
-
-Cron script to generate usage notifications for volumes existing during
-the audit period.
-
-Together with the notifications generated by volumes
-create/delete/resize, over that time period, this allows an external
-system consuming usage notification feeds to calculate volume usage
-for each tenant.
-
-Time periods are specified as 'hour', 'month', 'day' or 'year'
-
-hour = previous hour. If run at 9:07am, will generate usage for 8-9am.
-month = previous month. If the script is run April 1, it will generate
-        usages for March 1 through March 31.
-day = previous day. if run on July 4th, it generates usages for July 3rd.
-year = previous year. If run on Jan 1, it generates usages for
-     Jan 1 through Dec 31 of the previous year.
-
-
-OPTIONS
-=======
-
- **General options**
-
-FILES
-========
-
-* /etc/nova/nova.conf
-
-SEE ALSO
-========
-
-* `OpenStack Nova <http://nova.openstack.org>`__
-* `OpenStack Nova <http://nova.openstack.org>`__
-
-BUGS
-====
-
-* Nova is sourced in Launchpad so you can view current bugs at `OpenStack Nova <http://nova.openstack.org>`__
diff --git a/doc/source/man/nova-volume.rst b/doc/source/man/nova-volume.rst
deleted file mode 100644
index 4c695c841..000000000
--- a/doc/source/man/nova-volume.rst
+++ /dev/null
@@ -1,54 +0,0 @@
-===========
-nova-volume
-===========
-
--------------------
-Nova Volume Server
--------------------
-
-:Author: openstack@lists.launchpad.net
-:Date:   2012-09-27
-:Copyright: OpenStack LLC
-:Version: 2012.1
-:Manual section: 1
-:Manual group: cloud computing
-
-SYNOPSIS
-========
-
-  nova-volume [options]
-
-DESCRIPTION
-===========
-
-nova-volume manages creating, attaching, detaching, and persistent storage.
-
-Persistent storage volumes keep their state independent of instances.  You can
-attach to an instance, terminate the instance, spawn a new instance (even
-one from a different image) and re-attach the volume with the same data
-intact.
-
-
-OPTIONS
-=======
-
- **General options**
-
-FILES
-========
-
-* /etc/nova/nova.conf
-* /etc/nova/policy.json
-* /etc/nova/rootwrap.conf
-* /etc/nova/rootwrap.d/
-
-SEE ALSO
-========
-
-* `OpenStack Nova <http://nova.openstack.org>`__
-* `OpenStack Nova <http://nova.openstack.org>`__
-
-BUGS
-====
-
-* Nova is sourced in Launchpad so you can view current bugs at `OpenStack Nova <http://nova.openstack.org>`__