John Griffith 689d94e04e Handle TFlow short comings in SF driver
Taskflow by default does an auto retry of failed driver
calls.  By default the behavior is to retry unless the
exception is added to a blacklist, this has caused
issues in the past and we should probably fix it.

For now, this patch addresses a combination of issues that
result from Taskflows retry policy and the new object/HA
code changes that have been added to the cinder.volume.manager
code.

It's possible currently for a create to be issued to a volume
driver and for a volume to be created, BUT if anything goes
wrong on some subsequent operation (like setting up replication)
and an exception is thrown.  The changes to the manager code
now actively clear the host column prior to the retry (first problem),
then we go through and repeat 3 times.

The result here is that we end up with at least 3 orphaned volumes
on the backend device.  Also, now when you delete the error state
volume that Cinder still knows about, the code checks the host column
sees it's empty and of course can't issue a call to a driver, so it
just pretends things are ok, deletes the DB entry and moves on.

So now you have 3 orphaned volumes on the backend device that you
don't know about.  The logs don't contain any information to point
this out, and there's no mechanism in cinder to clean these
orphaned volumes up.

For now this patch just fixes things in the SF driver.
The only place we really have a potential of hitting this case
in the SF driver right now is if something fails in replication
setup after the create, so we'll just detect this scenario
ourselves and delete the volume from the backend before
returning the exception.

NOTE that this patch is part of the add_cheesecak_to_solidfire topic
chain of patches, and gerrit seems aware of it, although we don't get
the fancy "depends on" anymore.

Change-Id: Ib0c258046abc315993880eacfa190b957eaaed50
2016-04-18 15:18:19 +00:00
2012-05-03 10:48:26 -07:00
2012-05-03 10:48:26 -07:00
2012-05-03 10:48:26 -07:00
2015-06-11 17:19:19 +02:00
2016-03-02 14:33:25 -05:00
2016-03-24 09:46:21 -05:00
2015-09-18 16:37:17 +00:00

CINDER

You have come across a storage service for an open cloud computing service. It has identified itself as Cinder. It was abstracted from the Nova project.

Getting Started

If you'd like to run from the master branch, you can clone the git repo:

git clone https://git.openstack.org/openstack/cinder.git

For developer information please see HACKING.rst

You can raise bugs here http://bugs.launchpad.net/cinder

Python client

https://git.openstack.org/cgit/openstack/python-cinderclient

Description
OpenStack Block Storage (Cinder)
Readme 914 MiB
Languages
Python 99.7%
Smarty 0.3%