On 04 Apr 2014, at 07:33, Kirill Izotov <enyk...@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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
