Send 'create volume from snapshot' to the proper host

A simple solution for bug 1008866. When creating volume from snapshot on
multicluster, in volume it will check if snapshot_id is set. If snapshot_id
is set and FLAGS.snapshot_same_host is true, make the call create volume
directly to the volume host where the snapshot resides instead of passing it
through the scheduler. So snapshot can be copy to new volume. The same as
review 9761.

Change-Id: Ic182eb4563b9462704c5969d5116629442df316a
Fix traceback when detaching volumes via EC2

When detaching a volume from an instance it results
in the following traceback:

Cinderclient connection created using URL: http://192.168.1.103:8776/v1/bc02ec05c5fa4a5bb3020b617f3574e2
2012-08-06 18:58:32 ERROR nova.api.ec2 [req-1fd2f017-8a11-481f-b901-ae61d3f55c94 demo demo] Unexpected error raised: 'instance_uuid'
2012-08-06 18:58:32 TRACE nova.api.ec2 Traceback (most recent call last):
2012-08-06 18:58:32 TRACE nova.api.ec2   File "/opt/stack/nova/nova/api/ec2/__init__.py", line 474, in __call__
2012-08-06 18:58:32 TRACE nova.api.ec2     result = api_request.invoke(context)
2012-08-06 18:58:32 TRACE nova.api.ec2   File "/opt/stack/nova/nova/api/ec2/apirequest.py", line 81, in invoke
2012-08-06 18:58:32 TRACE nova.api.ec2     result = method(context, **args)
2012-08-06 18:58:32 TRACE nova.api.ec2   File "/opt/stack/nova/nova/api/ec2/cloud.py", line 799, in detach_volume
2012-08-06 18:58:32 TRACE nova.api.ec2     self.compute_api.detach_volume(context,volume_id=volume_id)
2012-08-06 18:58:32 TRACE nova.api.ec2   File "/opt/stack/nova/nova/compute/api.py", line 1642, in detach_volume
2012-08-06 18:58:32 TRACE nova.api.ec2     instance_uuid = volume['instance_uuid']
2012-08-06 18:58:32 TRACE nova.api.ec2 KeyError: 'instance_uuid'

By the time the volume in the cinder database the instance_uuid is already 'NULL',
so get the instance_uuid from the volume before its detached.

Fixes LP: #1033713

Change-Id: Id5515881b08af9d0832b4b620c03e471fdff0823
Signed-off-by: Chuck Short <chuck.short@canonical.com>
Driver for IBM Storwize and SVC storage.

Volume driver for IBM Storwize and SVC storage systems, along with unit
tests and updated sample config file. The unit tests include a
Storwize/SVC management simulator to allow for testing without
controller hardware. Also added a new exception for volume drivers.

Co-authored-by: Ronen Kat <ronenkat@il.ibm.com>

Change-Id: I3fe9cfcca8d4bddb71c763b526105e34f2652557
Make TerminateInstances compatible with EC2 api

fixes bug 1034377

Currently the XML response for TerminateInstances differs
from the EC2 api specifications and causes the .net EC2 api
from Amazon to crash.

Change-Id: I14172318ed4dc2af16c45be376475885f474c545
Fixes KeyError when trying to rescue an instance

When rescuing an instance, a KeyError exception is thrown since
the 'injected_files' key doesn't exist in the instance dict.

Change-Id: I733899c3f699803db4dbe95021b1cb6490392bed
Adds ability to inherit wsgi extensions

Needed for blueprint disable-server-extensions

It is possible to create a wsgi resource that extends another
resource by using the same controller, but any extensions that
have been applied to the original resource will have no affect.

This adds a new parameter to ResourceExtension that allows it
to inherit extensions from another resource. This is necessary
because we are moving key funcionality of the /servers resource
into extensions, and some other resources (like create-server-ext)
extend that functionality. This way we can keep the functionality
of the other extensions.

Change-Id: I21b4c2569c35d59c1f466642355564084a277aea
Fix setting admin_pass in rescue command

Fixes bug 1034948

The database doesn't have an admin_pass column, so the instance_update()
call is a noop.

Change-Id: I9f22de1e926ed48b8fd4561ddf2129db6a1e0b65
Fix stale instances being sent over rpc.

There were a number of places in compute/api.py that were calling
self.update() for an instance, but not sending an instance that contains
those updates over rpc.  This patch fixes them.

The changes to the unit tests were required because its stubs were
returning an instance without a host set in some cases.  So, the result
of self.update() had no host and the rpcapi would blow up since it had
no idea where to send the message.

This patch does not fix self.update() before prep_resize, because it is
being addressed in this patch: https://review.openstack.org/#/c/11050/

Change-Id: I4efc922a6a0af0605d4d63012d55ff8473211fd5
Merge "Fix setting admin_pass in rescue command"
Merge "Adds ability to inherit wsgi extensions"
Send updated instance model to schedule_prep_resize

A stale instance model was being passed to schedule_prep_resize.

Fixes bug 1034595

Change-Id: Ic92a22a2c315d25c70d32685fdf9f38451077b9a
Merge "Fix traceback when detaching volumes via EC2"
Merge "Send updated instance model to schedule_prep_resize"
Merge "Fix stale instances being sent over rpc."
Fix the inject_metadata_into_fs in the disk API.

Updates the _inject_metadata_into_fs in the disk/api.py so
that it uses dict-style access. This resolves an issue introduced
in a recent no-db-messaging change.

Includes new test case.

Fixes LP Bug #1034040.

Change-Id: I1bc90a8331419709ab71e5da8c48cd1d54c40f9e
Make update_db an opt arg in scheduler manager.

Updates the scheduler manager so that update_db is an optional
argument. This fixes issues when trying to make RPC calls
with the most recent version (1.4) of the scheduler RPC API.

Fixes LP Bug #1035004.

Change-Id: Ib998c0465cead1b8e117a7344557f8ff496c7e40
Merge "Make update_db an opt arg in scheduler manager."
Traceback when over allocating IP addresses

When a user over allocates a number of IP addresses
via euca-allocate-address, the user will get a nice
traceback saying that they over quota for IP address
allocation. Display a more userfriendly error when this
happens.

LP: #971609

Change-Id: If8586e246564f1069cb60bac9592f9d750522e81
Signed-off-by: Chuck Short <chuck.short@canonical.com>
Avoid double-reduction of quota for repeated delete.

Previously when an instance delete is repeated while a
delete is already in progress, the relevant quota usages
were reduced twice.

This is already healing logic in place to catch the special
case where these counts fall below zero, in which case the
sync method re-calculates the appropriate in-use count.

However this will only help the case at hand when the instance
count is itself trending towards zero, and not in general when
there's a healthy number of active instances.

Now we check the instance task state before making the quota
usage reduction.

Change-Id: I91a70ada01dbe050471da43d66774686782584ad
Merge "Make TerminateInstances compatible with EC2 api"