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
On 03 Apr 2014, at 12:49, Kirill Izotov enyk...@stackstorm.com 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
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.
==
...@yahoo-inc.com
Subject: Re: [openstack-dev] [Mistral] How Mistral handling long running
delegate tasks
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
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
On 02 Apr 2014, at 13:38, Kirill Izotov enyk...@stackstorm.com 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
(not for usage questions)
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Mistral] How Mistral handling long running
delegate tasks
Inline...
On Mar 27, 2014, at 5:10 PM, Joshua Harlow harlo...@yahoo-inc.com wrote:
Thanks for the description!
The steps here seem very
@lists.openstack.orgmailto:openstack-dev@lists.openstack.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
harlo...@yahoo-inc.commailto:harlo...@yahoo-inc.com wrote:
More responses inline :)
From
On 02 Apr 2014, at 05:45, Joshua Harlow harlo...@yahoo-inc.com 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
Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: Thursday, March 27, 2014 at 4:43 PM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Mistral] How Mistral handling long running delegate
@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Mistral] How Mistral handling long running
delegate tasks
Inline...
On Mar 27, 2014, at 5:10 PM, Joshua Harlow
harlo...@yahoo-inc.commailto:harlo...@yahoo-inc.com wrote:
Thanks for the description!
The steps here seem
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.
, 2014 at 4:43 PM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto: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
13 matches
Mail list logo
