Open Stack

Howdy,

Sandy is correct, we aren't doing automatic load-balancing of tasks/jobs
(currently).

Though there is nothing stopping this from being implemented (and I of
course would recommend adding it to taskflow rather than jumping to
gearman, but I am obviously biased),

A feature that appeared recently that can do this kind of load-balancing:

http://docs.openstack.org/developer/taskflow/conductors.html

A conductor 'group' (N-conductor processes for example) can examine attach
to jobboard[1] and decide how they want to select work (the load-balancing
part). This kind of filtering/balancing has been discussed and can likely
easily be implemented[2]; patches welcome ;)

My idea for jobs is that a job contains a 'large' unit of work (where
'large' is up to the taskflow user to define), the conductor or job
consumer would pick off the job in an atomic manner and then work on the
items in that job (jobs are typically composed of a logbook[3] that itself
contains a reference of flows/tasks to do). The granularity of the work in
the job is up to library users (although as others have stated the balance
needs to be determined by the taskflow user, since granularity affects
resumption and reversion processes).

[1] http://docs.openstack.org/developer/taskflow/jobs.html
[2] https://blueprints.launchpad.net/taskflow/+spec/job-filtering
[3] http://docs.openstack.org/developer/taskflow/persistence.html

-----Original Message-----
From: Sandy Walsh <sandy.walsh at RACKSPACE.COM>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Date: Tuesday, June 17, 2014 at 5:33 AM
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [taskflow] Recommendations for the
granularity of tasks and their "stickiness" to workers

>On 6/17/2014 7:04 AM, Eoghan Glynn wrote:
>> Folks,
>>
>> A question for the taskflow ninjas.
>>
>> Any thoughts on best practice WRT $subject?
>>
>> Specifically I have in mind this ceilometer review[1] which adopts
>> the approach of using very fine-grained tasks (at the level of an
>> individual alarm evaluation) combined with short-term assignments
>> to individual workers.
>>
>> But I'm also thinking of future potential usage of taskflow within
>> ceilometer, to support partitioning of work over a scaled-out array
>> of central agents.
>>
>> Does taskflow also naturally support a model whereby more chunky
>> tasks (possibly including ongoing periodic work) are assigned to
>> workers in a stickier fashion, such that re-balancing of workload
>> can easily be triggered when a change is detected in the pool of
>> available workers?
>
>I don't think taskflow today is really focused on load balancing of
>tasks. Something like gearman [1] might be better suited in the near term?
>
>My understanding is that taskflow is really focused on in-process tasks
>(with retry, restart, etc) and later will support distributed tasks. But
>my data could be stale too. (jharlow?)
>
>Even still, the decision of smaller tasks vs. chunky ones really comes
>down to how much work you want to re-do if there is a failure. I've seen
>some uses of taskflow where the breakdown of tasks seemed artificially
>small. Meaning, the overhead of going back to the library on an
>undo/rewind is greater than the undo itself.
>
>-S
>
>[1] http://gearman.org/
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev