Open Stack

On 04 Apr 2014, at 07:33, Kirill Izotov <enykeev at stackstorm.com> wrote:

>> Then, we can make task executor interface public and allow clients to
>> provide their own task executors. It will be possible then for Mistral
>> to implement its own task executor, or several, and share the
>> executors between all the engine instances.
> I'm afraid that if we start to tear apart the TaskFlow engine, it would quickly become a mess to support. Besides, the amount of things left to integrate after we throw out engine might be so low it proof the whole process of integration to be just nominal and we are back to square one. Any way, task execution is the part that least bothers me, both graph action and the engine itself is where the pain will be.

Would love to see something additional (boxed&arrows) explaining this approach. Sorry, I’m hardly following the idea.

>> That is part of our public API, it is stable and good enough. Basically,
>> I don't think this API needs any major change.
> 
>> But whatever should and will be done about it, I daresay all that work
>> can be done without affecting API more then I described above.
> 
> I completely agree that we should not change the public API of the sync engine, especially the one in helpers. What we need is, on the contrary, a low level construct that would do the number of things i stated previously, but will be a part of public API of TaskFlow so we can be sure it would work exactly the same way it worked yesterday.

I’m 99.99999% sure we’ll have to change API because all we’ve been discussing so far made me think this is a key point going implicitly through all our discussions: without have a public method like “task_done” we won’t build truly passive/async execution model. And it doesn’t matter wether it uses futures, callbacks or whatever else inside.

And again, just want to repeat. If we will be able to deal with all the challenges that passive/async execution model exposes then other models can be built trivially on top of it.

@Ivan,

Thanks for joining the conversation. Looks like we really need your active participation for you’re the one who knows all the TF internals and concepts very well. As for what you wrote about futures and callbacks, it would be helpful to see some illustration of your idea.

Renat Akhmerov
@ Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140404/13148fa9/attachment.html>