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:[email protected]] 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 <[email protected]<mailto:[email protected]>> 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...
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
