Open Stack

Sound then you ask, how does such a thing occur, well ask yourself how 
you'd know not to scheduler a contractor on the 23rd when your house 
gets demolished on the 21st. You'd probably be keeping a piece of paper 
around that says XYZ task is scheduled on ABC date, and before adding a 
new one you'd make sure that it doesn't conflict with any of the planned 
ones. Sounds like something that could be stored in a database (or a 
text file, or other...); of course it can get a-lot more complex (aka 
jeez that sounds like a query planner in way) but let's not go there 
right now :-P

Joshua Harlow wrote:
> 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 <harlowja at outlook.com
>> <mailto:harlowja at 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.thomas at gmail.com
>> <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>
>> <mailto: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...
>>
>> __________________________________________________________________________
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev