Move block_device_mapping update operations to conductor

This patch moves the uses of the following methods in compute/manager
to the conductor:

 - block_device_mapping_create()
 - block_device_mapping_update()
 - block_device_mapping_update_or_create()

As in the past with adding multiple similar operations to conductor,
only one method is actually added to the manager and RPC API, which
is similar to the update_or_create variant above. The public API for
conductor maintains all three variants and their original calling
conventions.

Related to blueprint no-db-compute-manager

Change-Id: Ibcb721ebd0ba8639ccb2ba2f7bed1dcf499e4edb
Move block_device_mapping get operations to conductor

This patch moves the block_device_mapping_get_by_instance()
uses from compute/manager to the conductor. This also includes
some nasty refactoring in some of compute's helper methods to
pass around instances instead of just uuids so that we can
properly pass the former to the conductor.

Related to blueprint no-db-compute-manager

Change-Id: Ib5223274d21096a9e47b3420c3de801b978b253d
Remove unused VMWare VIF driver abstraction

There is only a single VMWare VIF driver impl and that is
entirely a no-op in the plug & unplug methods. The VMWare
driver does call a 'ensure_vlan_bridge' method, which is
essentially a static helper for creating a bridge device.

Remove the VMWareVlanBridgeDriver class entirely and simply
have a single static method instead

Change-Id: I7d0873798e0e7261e17e8894237fd4339be7c3cd
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Invalid EC2 ids should make the entire request fail.

Resolves bug 836978. I suspect there are many other cases where we
should add this check.

Change-Id: I027e44db2e27eb1ef913ddad8560cca08388906b
fix floating-ip in multihost case

Fixes bug 1091698.

_disassociate_floating_ip and _associate_floating_ip got an extra
parameter since this change:
https://github.com/openstack/nova/commit/b93e851c0d90c17868a0e68a3b54e136bb5cd54d
However, the multi-host codepath was not amended, thus multihost case
is broken since that. This fix adds the extra parameters for those rpc
calls.

Change-Id: I93a5f96ef87c0f8a14c912d7812c001d0c682afa
Move block_device_mapping destroy operations to conductor

This patch moves the compute/manager's use of block_device_mapping_destroy
operations to the conductor. Specifically:

 - block_device_mapping_destroy()
 - block_device_mapping_destroy_by_instance_and_device()
 - block_device_mapping_destroy_by_instance_and_volume()

Once again, this just adds a single destroy operation to the conductor's
RPC API and replicates the older interfaces in the public API. Further,
the first now takes a list of bdms to be destroyed (unlike the db
operation it mirrors) so that multiple RPC calls can be avoided for
bulk delete operations.

Related to blueprint no-db-compute-manager

Change-Id: Ib93184ee6d32fcda90f75a26b579787e4625e9ae
Remove system_metadata db calls from compute manager

The compute/manager makes several unnecessary db calls to fetch
the instance system_metadata, which is available in the instance
object itself now. This patch replaces those uses, avoiding the
need to farm them out to conductor.

Related to bp/no-db-compute
Related to bp/no-db-compute-manager

Change-Id: I26ff77be17eb538a4fcd238ffe52f8bde4fbe3e0
Sync timeutils changes from Oslo

Change-Id: I5eddfbad43a2f57e6b2af6299e480c32b11a5d19
Allow larger encrypted password posts to metadata

System Metadata only supports values up to 255 characters, but
passwords encrypted with an rsa key are generally much longer than
that, so we support longer passwords by chunking into four fields.

Change-Id: Iceae6cbc7609ec3bdf1b3814aec5b73f19613349
Merge "Allow larger encrypted password posts to metadata"
Cells: Add the main code.

This introduces *EXPERIMENTAL* compute cells functionality as a way to
scale nova in a more distributed fashion without having to use complicated
technologies like DB and message queue clustering.

Cells are configured as a tree and the top level cell should contain
nova-api without any nova-computes while child cells contain everything
except nova-api.  One can think of a cell as a normal nova deployment in
that each cell has its own DB server and message queue broker.

The top level cell keeps a subset of data about ALL instances in all
cells in its DB.  Child cells send messages to the top level cell when
instances change state.  Data in 1 child cell is not shared with another
child cell.

A new service, nova-cells, is introduced that handles communication
between cells and picking of a cell for new instances.  This service is
required for every cell.  Communication between cells is pluggable with
the only option currently implemented being communnication via RPC.

Cells scheduling is separate from host scheduling.  nova-cells first picks
a cell (currently randomly -- future patches add filtering/weighing
functionality and decisions can be based on broadcasts of
capacity/capabilities).  Once a cell has been selected and the new build
request has reached its nova-cells service, it'll be sent over to the host
scheduler in that cell and the build proceeds as it does without cells.

New config options are introduced for enabling and configuring the cells
code.  Cells is disabled by default.  All of the config options below go
under a '[cells]' section in nova.conf.  These are the options that one
may want to tweak:

enable -- Turn on cells code (default is False)
name -- Name of the current cell.
capabilities -- List of arbitrary key=value pairs defining capabilities
                of the current cell.  These are sent to parent cells,
                but aren't used in scheduling until later filter/weight
                support is added.
call_timeout -- How long to wait for replies from a calls between cells

When using cells, the compute API class must be changed in the API cell,
so that requests can be proxied via nova-cells down to the correct cell
properly.  Thus, config requirements for API cell:

--
[DEFAULT]
compute_api_class=nova.compute.cells_api.ComputeCellsAPI.
[cells]
enable=True
name=api-cell
--

Config requirements for child cell:

--
[cells]
enable=True
name=child-cell1
--

Another requirement is populating the 'cells' DB table in each cell.
Each cell needs to know about its parent and children and how to
communicate with them (message broker location, credentials, etc).

Implements blueprint nova-compute-cells

DocImpact

Change-Id: I1b52788ea9d7753365d175abf39bdbc22ba822fe
Merge "Invalid EC2 ids should make the entire request fail."
Merge "Cells: Add the main code."
Merge "Remove unused VMWare VIF driver abstraction"
Merge "fix floating-ip in multihost case"
Merge "Move block_device_mapping update operations to conductor"
Merge "Move block_device_mapping get operations to conductor"
Merge "Move block_device_mapping destroy operations to conductor"
Merge "Remove system_metadata db calls from compute manager"
Merge "Sync timeutils changes from Oslo"