Open Stack

Hi,

Thanks guys for bringing this topic up to discussion. In my opinion, this feature is extremely important and will move Mistral further to being a truly useful tool. I think it’s one of the “must have” feature of Mistral.


> On 31 Mar 2015, at 08:56, Dmitri Zimine <dzimine at stackstorm.com> wrote:
> 
> @Lingxian Kong
>>  The context for a task is used
>> internally, I know the aim for this feature is to make it very easy
>> and convinient for users to see the details for the workflow exection,
>> but what users can do next with the context? Do you have a plan to
>> change that context for a task by users? if the answer is no, I think
>> it is not very necessary to expose the context endpoint.
> 
> I think the answer is “yes users will change the context” this falls out of use case #3. 
> Let’s be specific: a create_vm task failed due to, say, network connection. 
> As a user, I created the VM manually, now want to continue the workflow. 
> Next step is attach storage to VM, needs VM ID published variable. So a user needs to 
> modify outgoing context of create_vm task.

Agree with Dmitri here.


> May be use case 2 be sufficient? 
> We are also likely to specify multiple tasks: in case a parallel execution of two tasks
> (create VM, create DNS record) failed again due to network conditions - than network 
> is back I want to continue, but re-run those two exact tasks. 
> 
> Another point, may be obvious but let’s articulate it: we re-run task, not individual action within task.
> In context of with_items, retry, repeat, it will lead to running actions multiple times.
> 
> Finally, workflow execution traceability. We need to get to the point of tracing pause and resume as workflow events. 
> 
> @Lingxian Kong
>>  we can introduce the notification
>> system to Mistral, which is heavily used in other OpenStack projects.
> care to elaborare? Thanks! 

I’m curious too. Lingxian, could you please explain more detailed what you mean exactly?

>> On Fri, Mar 27, 2015 at 11:20 AM, W Chan <m4d.coder at gmail.com <mailto:m4d.coder at gmail.com>> wrote:
>>> We assume WF is in paused/errored state when 1) user manually pause the WF,
>>> 2) pause is specified on transition (on-condition(s) such as on-error), and
>>> 3) task errored.
>>> 
>>> The resume feature will support the following use cases.
>>> 1) User resumes WF from manual pause.
>>> 2) In the case of task failure, user fixed the problem manually outside of
>>> Mistral, and user wants to re-run the failed task.
>>> 3) In the case of task failure, user fixed the problem manually outside of
>>> Mistral, and user wants to resume from the next task.
>>> 
>>> Resuming from #1 should be straightforward.

Just to clarify: this already works.

>>> Resuming from #2, user may want to change the inbound context.
>>> Resuming from #3, users is required to manually provide the published vars
>>> for the failed task(s).


These two cases is basically what we need to implement.

Winson, very good and clear summary (at least to me). I would suggest we prepare a little bit more formal (but not too much) spec of what we’re going to do here. A few examples would help us understand the topic better. So specifically, it would be interesting to see:

What endpoints we are going to add and how approximately they would look (calculating requirements that need to be satisfied in order to resume workflow, task contextx).
A few typical scenarios of resuming a workflow with explanations of how we modify contexts or published vars and how we resume the workflow. The trivial case (#1) can be skipped as it’s already implemented.
Roughly formed suggestions on how that all could be implemented.

This is just my preference to see something like this but at the same time I personally don’t want you to spend much time on that but if it’s possible to prepare it within a reasonable amount of time that would be helpful

Thanks

Renat Akhmerov
@ Mirantis Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150331/7073b2f2/attachment-0001.html>