Duncan Thomas wrote:
On 29 June 2015 at 18:18, Joshua Harlow <[email protected]
<mailto:[email protected]>> 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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
