Open Stack

Duncan Thomas wrote:
> On 29 June 2015 at 18:18, Joshua Harlow <harlowja at outlook.com
> <mailto:harlowja at outlook.com>> 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.
>
>
> That should be fun to code - you'd need to have current and future
> states of all tasks, and an atomic transactional way of changing the
> future state, from any API service... I'd say it's better to accept all
> tasks and report failure for the ones who had their resource go away
> before they got executed... far less needed in the way of transactional
> atomic primatives - you can just lock the state of each needed resource,
> as long as it is always in some defined order, you don't deadlock, and
> if a resource is found in a bad state, release (in reverse order) and
> fail the task.

Sure, sounds like something like an 'execution planner' (for lack of 
better terms) or u just look at how you'd do this in the real world and 
mimic that (us humans seem to have found a way to do this, without to 
much issue, so I don't see why computers shouldn't be able to mirror 
something similar).

>
>     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)...
>
>
> If cancelling a contractor is cheap and booking one at the last second
> is expensive (or you schedule is very busy and unclear), then maybe you
> do...

Or just don't be nutty and book contracts after your house is 
demolished, less nutty people ftw ;)

>
> __________________________________________________________________________
> 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