On 04 Apr 2014, at 07:33, Kirill Izotov 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 i
> 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 t
ample?).
Maybe some example/POC code would help all :-)
-Josh
-Original Message-
From: Ivan Melnikov
Date: Thursday, April 3, 2014 at 12:04 PM
To: "OpenStack Development Mailing List (not for usage questions)"
, Joshua Harlow
Subject: Re: [openstack-dev] [Mistral] How Mistra
I'm trying to catch up this rather long and interesting discussion,
sorry for somewhat late reply.
I can see aspects of 'lazy model' support in TaskFlow:
- how tasks are executed and reverted
- how flows are run
- how engine works internally
Let me address those aspects separately.
== Executing
On 03 Apr 2014, at 12:49, Kirill Izotov wrote:
> Actually, the idea to make the concept more expandable is exactly my point =)
> Mistral's Workbook is roughly the same as TaskFlow Flow and have nothing to
> do with TaskFlow LogBook. The only major difference in case of Workbook is
> that we h
On 02 Apr 2014, at 13:38, Kirill Izotov wrote:
> I agree that we probably need new engine for that kind of changes and, as
> Renat already said in another thread, lazy model seems to be more basic and
> it would be easier to build sync engine on top of that rather than other way
> around. Yes,
On 02 Apr 2014, at 05:45, Joshua Harlow wrote:
> Possibly, although to me this is still exposing the internal of engines to
> users who shouldn't care (or only care if they are specifying an engine type
> that gives them access to these details). Allowing public access to these
> API's worries
tack.org>>
Subject: Re: [openstack-dev] [Mistral] How Mistral handling long running
delegate tasks
Even more responses inline :)
On Mar 31, 2014, at 8:44 PM, Joshua Harlow
mailto:harlo...@yahoo-inc.com>> wrote:
More responses inline :)
From: Dmitri Zimine mailto:d...@stackstorm.com>>
>
> Repeater does sound nice also though, damn naming of 'things' ;)
>
> For retries on individual tasks since taskflow supports flow nesting its not
> that hard to do this (although it might not be the most elegant).
>
> >>> flow = LinearFlow("blah blah&
tack.org>>
Subject: Re: [openstack-dev] [Mistral] How Mistral handling long running
delegate tasks
Inline...
On Mar 27, 2014, at 5:10 PM, Joshua Harlow
mailto:harlo...@yahoo-inc.com>> wrote:
Thanks for the description!
The steps here seem very much like what a taskflow engine does (which i
s data for various reasons is reacher then 'retry'.
What about the 'retry policy' on individual task?
>
> From: Dmitri Zimine
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>
> Date: Thursday, March 27, 2014 at 4:43 PM
>
te: Thursday, March 27, 2014 at 4:43 PM
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Mistral] How Mistral handling long running delegate
tasks
Following up on http://tinyurl.com/l8gtmsw and http:
Following up on http://tinyurl.com/l8gtmsw and http://tinyurl.com/n3v9lt8:
this explains how Mistral handles long running delegate tasks. Note that a
'passive' workflow engine can handle both normal tasks and delegates the same
way. I'll also put that on ActionDesign wiki, after discussion.
Di
13 matches
Mail list logo
