Duncan Thomas wrote:
Do we know what is so hated about the glance task API? Tasks and entity queues give the required exclusion, if you accept that tasks can fail if previous tasks in the queue can cause things to be pulled out from under it.
Sounds like certain tasks shouldn't of been accepted in the first place then no? Sounds like before acceptance of a piece of work there needs to be some verification that what is being requested doesn't conflict with what is underway/planned.
After all you don't try to hire a contractor to fix your plumbing on the 23rd of the month if your house is scheduled to be demolished on the 21st (analogies ftw)...
-Josh
On 29 June 2015 at 17:22, Joshua Harlow <harlo...@outlook.com <mailto:harlo...@outlook.com>> wrote: Is the V3 api going to be a task API like nova desires (someday it will happen in nova to)? If so then it seems like a natural fit for this (aka submit a request, get back a task json object that can be polled on, one of those polling states it reports back is 'WAITING' or 'BLOCKED' or ...) Dulko, Michal wrote: 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.tho...@gmail.com <mailto:duncan.tho...@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.du...@intel.com <mailto:michal.du...@intel.com> <mailto:michal.du...@intel.com <mailto:michal.du...@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... __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
