Fix HP LeftHand migration with snapshots

Check for snapshots associated with volumes during assisted
migration, and fail if a snapshot is found.

When a volume is cloned on the HP LeftHand array, a snapshot
is created and the cloned volume is created from the snapshot.
The snapshot remains associated with the newly created volume.
Therefore, backend assisted migration should check for volumes
with snapshots and not use native APIs to migrate any volume
that has a snapshot.

Change-Id: I29fc3dbd1f24c01968e7c3d043cdf6b9d1b89ee9
Closes-Bug:#1285829
Add user defined extra capabilities

Provide a mechanism that will allow sys admins who are managing cinder
installations with multiple backends to assign key/value pairs to
backends. The key/value pairs can be used by the capabilities scheduler
to select between backends when requests specify volume types.

For example a sysadmin could specify the key 'service_level' with the
values 'high', 'medium' and 'low' for different backends. The sys admin
specifies the 'service_level' for each backend in cinder.conf as a json
string, for example:

extra_capabilities='{"service_level"="high"}'

or

extra_capabilities='{"service_level"="medium"}'

DocImpact
Implements: blueprint admin-defined-capabilities
Change-Id: I1ee9dcb22b3f097c3f3b2a70b0cb672930407cc9
Volume manage/unmanage support

Implements: blueprint add-export-import-volumes

Volume manage/unmanage support.

This change adds two new API extensions:

volume_unmanage.py:
Adds an "os-unmanage" action on an existing volume, which causes a
delete operation to flow through the stack, with a flag that indicates
that a different method ("unmanage") should be called on the driver
instead of delete_volume. A default, empty, implementation of unmanage
is provided.

volume_manage.py
Adds a new "os-manage-volume" API. A POST to this URI is very similar to
volume creation, except that the images, snapshots and existing volumes
cannot be specified. Instead the following must be specified:

host: Cinder host on which the existing storage resides
ref: Driver-specific reference to the existing storage object

name, description, volume_type, metadata and availability_zone are
supported as per a normal volume creation.

In order to support some re-use between volume_manage and the regular
volume creation, add_visible_admin_metadata has been factored out into
the cinder utils.py module.

The rest of the changes are just the implications of the host/ref
specification moving through the api, rpcapi, manager and flow (API and
Manager) layers. Management of an existing volume causes the
manage_existing_get_size() and manage_existing() methods to be called on
the driver, and a reference LVM implementation is provided.
brick/local_dev/lvm.py now includes a method to rename an LV.

Change-Id: Ifc5255b2fd277c0f60d25fc82a777e405b861320
Storwize volume manage/unmanage support

IBM Storwize/SVC support for managing and unmanaging volumes.

Partially Implements: blueprint add-export-import-volumes

Change-Id: Ie90d5c0a18fcfcf7208990abf3476f432ea863c3
Merge "Fix HP LeftHand migration with snapshots"
Merge "Add user defined extra capabilities"
Merge "Volume manage/unmanage support"
Merge "Storwize volume manage/unmanage support"