stack.org>>
Date: Tuesday, April 1, 2014 at 2:59 PM
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Mistral][TaskFlow] Long running actions
On Apr 1, 2014, at 3:43 AM, Renat Akh
usage questions)"
>
> Subject: Re: [openstack-dev] [Mistral][TaskFlow] Long running actions
>
>>
>> On Apr 1, 2014, at 3:43 AM, Renat Akhmerov wrote:
>>> On 25 Mar 2014, at 01:51, Joshua Harlow wrote:
>>>
>>>> The first execution model I
st (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Mistral][TaskFlow] Long running actions
On Apr 1, 2014, at 3:43 AM, Renat Akhmerov
mailto:rakhme...@mirantis.com>> wrote:
On 25 Mar 2014, at 01:51, Joshua Harlow
mailto:harlo...@yahoo-i
st (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Mistral][TaskFlow] Long running actions
On 25 Mar 2014, at 01:51, Joshua Harlow
mailto:harlo...@yahoo-inc.com>> wrote:
The first execution model I would call the local execution m
On Apr 1, 2014, at 3:43 AM, Renat Akhmerov wrote:
> On 25 Mar 2014, at 01:51, Joshua Harlow wrote:
>
>> The first execution model I would call the local execution model, this model
>> involves forming tasks and flows and then executing them inside an
>> application, that application is runnin
On 25 Mar 2014, at 01:51, Joshua Harlow wrote:
> The first execution model I would call the local execution model, this model
> involves forming tasks and flows and then executing them inside an
> application, that application is running for the duration of the workflow
> (although if it cras
above, I don't know, but
thats why it's a POC.
-Josh
From: Joshua Harlow mailto:harlo...@yahoo-inc.com>>
Date: Friday, March 21, 2014 at 1:14 PM
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Cc: &qu
or this
> type of usage) and they would also be releasing the work back for others to
> 'take-over' when there own zookeeper connection is lost (zookeeper handles
> this this natively).
>
> --
>
> Now as for how much of mistral would change from the above, I do
On 03/21/2014 12:33 AM, W Chan wrote:
Can the long running task be handled by putting the target task in the
workflow in a persisted state until either an event triggers it or
timeout occurs? An event (human approval or trigger from an external
system) sent to the transport will rejuvenate the
14 PM
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Cc: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Mistral][TaskF
Will advise soon, out sick with not so fun case of poison oak, will reply next
week (hopefully) when I'm less incapacitated...
Sent from my really tiny device...
On Mar 21, 2014, at 3:24 AM, "Renat Akhmerov"
mailto:rakhme...@mirantis.com>> wrote:
Valid concerns. It would be great to get Joshua
Valid concerns. It would be great to get Joshua involved in this discussion. If
it’s possible to do in TaskFlow he could advise on how exactly.
Renat Akhmerov
@ Mirantis Inc.
On 21 Mar 2014, at 16:23, Stan Lagun wrote:
> Don't forget HA issues. Mistral can be restarted at any moment and need
Don't forget HA issues. Mistral can be restarted at any moment and need to
be able to proceed from the place it was interrupted on another instance.
In theory it can be addressed by TaskFlow but I'm not sure it can be done
without complete redesign of it
On Fri, Mar 21, 2014 at 8:33 AM, W Chan w
Can the long running task be handled by putting the target task in the
workflow in a persisted state until either an event triggers it or timeout
occurs? An event (human approval or trigger from an external system) sent
to the transport will rejuvenate the task. The timeout is configurable by
the
> For the 'asynchronous manner' discussion see http://tinyurl.com/n3v9lt8; I'm
> still not sure why u would want to make is_sync/is_async a primitive concept
> in a workflow system, shouldn't this be only up to the entity running the
> workflow to decide? Why is a task allowed to be sync/async,
15 matches
Mail list logo
