Open Stack

That’s right, it might be painful. V3 API implememtation would be also a hard, because then we would need different manager behavior for requests from V2 and V3… So maybe we need some config flag with deprecation procedure scheduled?

From: Duncan Thomas [mailto:duncan.thomas at gmail.com]
Sent: Monday, June 29, 2015 2:46 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder][oslo] Locks for create from volume/snapshot

On 29 June 2015 at 15:23, Dulko, Michal <michal.dulko at intel.com<mailto:michal.dulko at intel.com>> wrote:
There’s also some similar situations when we actually don’t lock on resources. For  example – a cgsnapshot may get deleted while creating a consistencygroup from it.

From my perspective it seems best to have atomic state changes and state-based exclusion in API. We would need some kind of currently_used_to_create_snapshot/volums/consistencygroups states to achieve that. Then we would be also able to return VolumeIsBusy exceptions so retrying a request would be on the user side.


I'd agree, except that gives quite a big behaviour change in the tenant-facing API, which will break clients and scripts. Not sure how to square that circle... I'd say V3 API except Mike might kill me...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150629/47f467e0/attachment.html>