Prevent the unexpected with nova-manage network modify.

"nova-manage network modify" can misinterpret arguments if the user
provides values where they are unexpected, specifically the
--disassociate-project and --disassociate-host options. If the user
provides a project or hostname value for either of these values, it will
be interpreted as a positional argument and modify handler may behave as
if other options were provided (e.g. project or host).

This change handles the presence of a project or host option along with
--disassociate-project or --disassociate-host as an error, printing a
message and exiting immediately with an error code. While there are
other approaches (e.g. perform the disassociate modifications while
ignoring the others), preventing unexpected or inconsistent results by
doing nothing seems safest.

Change-Id: Iff7817fe3ed19a4ff330b4029f9c558d3b405e9b
Refactor nwfilter parameters

* libvirt < 1.0.1 does not allow dynamically updating filter
  parameters inside an interface block of theinstance XML. To
  address this we move the nwfilter paramters from the instance
  XML to the per-instance base nwfilter.

Relates to bug #1124722

Change-Id: I50ec5dcffa8ff0232ae0aba0a08fce5151962238
Fix handling of source_groups with no-db-compute.

The moving of data around in no-db-compute broke source groups. This
is a combination of a few errors. First, the instance_type data wasn't
being retrieved from system_metadata. Second, the instance_type data
was too deep in the heirarchy and being ignored. Finally, source
groups require a nw info call which causes a db access by
nova-compute.

Fixes bug 1122316

Change-Id: Iccb6e5d336c0b2c8ba41c41ab2e046fc9617835a
Add better status to baremetal deployments.

This patch introduces a few new baremetal states, which are used to
track the deploy process. Now, nova-baremetal-deploy-helper updates the
bm_nodes record directly when it begins and finishes deploying an image
to that node.

The next patch will add a LoopingCall inside driver.spawn() to wait for
the deploy to complete.

Also, since there can not be >1 active deployment per node, there
is no need to have a separate table for storing them. This patch drops
the table bm_deployments and adds the important information it contained
to bm_nodes. Since the previous behavior was to mark a deployment as
deleted once it completed, there is no need to copy any data from
bm_deployments prior to dropping the table -- assuming that no active
deployments are in process when the migration is run.

Since this is the first migration for the baremetal database, it also
adds a new test class, TestBaremetalMigrations, and refactors the
test_migrations.py file to allow for multiple test classes.

partially implements fix for bug 1096723

Change-Id: Iad30b462d49c88fc19babed43a2fb8540b1fad30
Merge "Prevent the unexpected with nova-manage network modify."
Merge "Fix handling of source_groups with no-db-compute."
Add a volume driver in Nova for Scality SOFS

Scality SOFS is a network filesystem mounted with FUSE, with most
options given in a configuration file. Given a mount point and a SOFS
configuration file as driver options, the Scality volume driver mounts
SOFS, and then creates, accesses and deletes volumes as regular
(sparse) files on SOFS.

Change-Id: I84bf268e5a2c5c33b8706830e8067914fae44aed
Implements: blueprint scality-volume-driver
cfg should be imported from oslo.config

Change-Id: Idd9c3ededd2f63156eb78ed01fd38ddb3a20437f
Merge "Add better status to baremetal deployments."
Merge "Add a volume driver in Nova for Scality SOFS"
Merge "cfg should be imported from oslo.config"
Merge "Refactor nwfilter parameters"