Switch to Oslo-Incubator's EnvFilter rootwrap

Nova-Network used to have its own class for DnsMasq rootwrap
filtering. This was generalized into a new EnvFilter rootwrap
filter that can specify both commands and environments to pass.

Update to openstack.common.rootwrap to git a117358 of
oslo-incubator's rootwrap. This includes the following commits
merged from oslo:

    3b16d31 Remove DnsmasqFilter and DeprecatedDnsmasqFilter
    f9d1a59 Handle empty arglists in Filters
    233baa2 Handle empty PATH environment variable
    3e74c00 Add IpFilter, IPNetnsExecFilter and EnvFilter
    8b95b1e Handle relative path arguments in Killfilter
    7119e29 Enable hacking H404 test.
    ea78eec Update KillFilter to stop at '\0' for readlink() function.

Related to: blueprint quantum-common-rootwrap

Change-Id: I125e5724259850dc4768fb236cbfa5df199008c0
Removed code for modular exponentiation, pow() already does this

Change-Id: If21cbcbeb60618769e1659a90381416dfc43ebc4
Cleanup exception handling on evacuate

Some cleanup around catchall exception handing
on evacuate v2 extension to bring it in line
with v3 exception handling. Tests included.

Fixes bug 1210570

Change-Id: I2f2f958acb80240c0fb25f3d538fa204611a33d1
Fix H501: Do not use locals() for string formatting

Change-Id: Ide587d3311c22f698a82eeee210c5bdbe24eb484
Remove clear_rabbit_queues script

The clear_rabbit_queues script has been around forever, but it doesn't
appear to be widely used - e.g. there is no user documentation for it
and I don't see any mentions of it on mailing lists or Q&A forums.

Also, RabbitMQ now includes a management plugin and CLI which allows
you do do e.g.

  $> rabbitmqadmin delete queue name=$topic
  $> rabbitmqadmin delete queue name=$topic.$host
  $> rabbitmqadmin delete exchange name=nova

oslo.messaging does not expose an API equivalent of this command since
even the existance of a queue is transport driver specific. We could
consider adding transport-specific admin CLIs, but probably not where
the transport already has suitable admin CLIs elsewhere.

For reference, this script was added by this merge:

  https://code.launchpad.net/~mdragon/nova/lp794635/+merge/71437

blueprint: oslo.messaging
Change-Id: If5e6354e8ace4c0b4425c96de558a5cbab4c98bd
Port "Accept is_public=None .." to v3 tree

The following commit(I2a9b1c24cd744c8819c1d41e0ad103d05398401c) have
not been merged to v3 tree now, because the commit was merged to the
existing api after porting flavors.py to v3 tree.

    commit 645c2d3a06bbf8b0854ebcc539ad33dd706866c5
    Author: Xavier Queralt <xqueralt@redhat.com>
    Date:   Wed Jun 12 14:59:29 2013 +0200

        Accept is_public=None when listing all flavors

This patch ports the commit to v3 tree.

Partially implements blueprint nova-v3-api

Change-Id: Id1ff1366c16f0caac50e279b2add5ec9d9b9bf5f
Moves compute.rpcapi.prep_resize call to conductor

This patch moves the prep_resize logic out of scheduler.manager
and creates it on conductor.manager.ComputeTaskManager.

Partially implements bp cold-migrations-to-conductor

Change-Id: I8458071fb13505f55f8d2155c9ec5ee938b1005f
Merge "Fix H501: Do not use locals() for string formatting"
Merge "Cleanup exception handling on evacuate"
Merge "Port "Accept is_public=None .." to v3 tree"
Merge "Remove clear_rabbit_queues script"
Merge "Removed code for modular exponentiation, pow() already does this"
Merge "Moves compute.rpcapi.prep_resize call to conductor"
Merge "Switch to Oslo-Incubator's EnvFilter rootwrap"
remove _action_change_password the attribute in V3 server API

There is no implementation of _action_change_password for the
attribute of ActionDeserializer in V3 server API. Get rid of it

fix bug 1209072

Change-Id: I37019811caa71c491c228b99babfcfb34bbaa685
Make API part of instance boot use new BDM format

This patch makes the API part of the instance boot process rely on the
new BDM format. It adds additional validations that are enabled due to
using the new format.

Since the new format will allow to specify devices that will be created
as images on the hypervisor (if the hypervisor enables it), in order
to prevent a DOS, a new config option 'max_local_block_devices' was
added. This option allows the operator to set a limit on the number of
destination_type='local' block devices a user can specify per VM.

This patch also refactors and simplifies how block devices are handled
during boot, and makes sure that validation errors are caught and
transformed to expected HTTP errors.

Change-Id: I62e0807fcff0a284ff72555d107cac1c9864e46d
blueprint: improve-block-device-handling
Change RPC to use new BDM format for instance boot

This patch makes rpc calls that are the result of booting an instance
propagate the new block device mapping format.

The way this is done is by adding a 'legacy_bdm' flag to the conductor
(task) API. Since both the scheduler and the compute service propagate
the block device mapping as part of the request_spec field, a flag named
legacy_bdm_in_spec to indicate that was introduced in their respective
APIs.

Currently block_device_mapping is not used by any of the in-tree filters
in the scheduler, so it is assumed that scheduler's boot functionality
has now transitioned to the new format.

This patch also bumps RPC versions of the task, scheduler and compute
manager classes.

Finally this patch propagates the legacy_bdm_in_spec through the
run_instance callback of the compute manager so that, in case of error -
the instance is re-scheduled with the proper flag set.

blueprint: improve-block-device-handling

Change-Id: I5f25ddd4d586dda91061f065c1796be726b0ede3
Refactor how BDMs are handled when booting

This patch refactors how block devices are handled when booting VMs.
Also it introduces new block device mapping format in the run_instance
manager method of the compute service.

The refactoring is done by creating a simple hierarchy of
DriverBlockDevice classes that are meant to:

1) Provide a common place to keep information about the data that is
kept for each block device type

2) Encapsulate the logic of "attaching" the device from the compute
service point of view (driver will still need to do the actual work).

Currently we have special subclasses for ephemeral, swap, volume and
snapshot devices.

These classes also make it possible to easily provide
the drivers that will require old block device mapping format with it by
overriding the legacy() method.

Another advantage that this refactoring brings is that adding additional
block device types, like Image block devices (coming soon in a subsequent
patch) that can have destination type of either a hypervisor image or a
volume will be just a matter of extending the base class and redefining
attach to do the work of creating the volume if needed.

blueprint: improve-block-device-handling

Change-Id: I5b9c3e2d959c602fa22f49db681da918ae0adcea
Virt driver flag for different BDM formats

This patch introduces a new virt driver property
'need_legacy_block_device_info' that will tell the compute manager if
driver needs to be passed legacy block_device_info.

This patch also refactors the compute manager methods that would pass
the block device info to driver methods - to do so according to the
property of the driver. This is done by moving all the code into a single
private method _get_instance_volume_block_device_info. This method existed
before but now uses the new DriverBlockDevice classes for it's
functionality.

As it is sometimes necessary to refresh the connection info for volume
based DriverBlockDevice objects (a private manager method
_refresh_block_device_connection_info was used for this), this patch
also factors this code to a method on the DriverVolumeBlockDeviceClass,
and is now completely used like that when needed, and removes the said
method.

Finally - this patch removes a _get_block_device_info method from the
compute API class. This remained from early pre-conductor attempts to
remove DB access from the compute service, and is irrelevant now that
conductor is used. This is needed so that the source  of block device
data is always conductor and the version of data is always
known.

After this patch - it will be possible to implement changes in drivers
that will allow them to utilise the new block device data format.

blueprint: improve-block-device-handling

Change-Id: If961329061e5413824d891eada645dd8dd9cb6dd
Allow more than one ephemeral device in the DB

This patch changes the database api behaviour when creating/updating a
block device mapping to allow more than one ephemeral device instead of
overriding the old ones.

Part of blueprint: improve-block-device-handling

Change-Id: I71c283cbd5ad3d28a27d06cb01b5ba9433f8ab46