Open Stack

Hi, Renat,

Actually, I have the same idea months ago, but what I thought is to provide
task dependencies information in a workflow definition, since as a workflow
designer, I have no idea about how my workflow 'looks like', unless I
create an execution with that, especially when there are a lot of tasks
within workflow definition.

And what you want to address here is to get execution/task-execution
dependencies information in run time, which also will give users more
detailed information about what happened in the system, I'd like to see it
landed in Mistral.

To achieve that, we should record the execution/task-execution relationship
during an execution is running, because we have no such info currently.

On the CLI side, I agree we add option to 'execution-get' command, and
accordingly we could add a new column 'dependent on' or 'parent' or
something else to the result.

On Tue, Sep 1, 2015 at 1:47 AM, Joshua Harlow <harlowja at outlook.com> wrote:

> Would u guys have any use for the following being split out into its own
> library?
>
> https://github.com/openstack/taskflow/blob/master/taskflow/types/tree.py
>
> It already has a pformat method that could be used to do your drawing of
> the 'tree'...
>
>
> http://docs.openstack.org/developer/taskflow/types.html#taskflow.types.tree.Node.pformat
>
> Might be useful for u folks? Taskflow uses it to be able to show
> information that is tree-like to the developer/user for similar purposes
> (it also supports using pydot to dump things out in dot graph format):
>
> For example http://tempsend.com/A8AA89F397/4663/car.pdf is the graph of
> an example (in particular
> https://github.com/openstack/taskflow/blob/master/taskflow/examples/build_a_car.py
> )
>
> -Josh
>
> Renat Akhmerov wrote:
>
>> Team,
>>
>> I’d like to discuss
>> https://blueprints.launchpad.net/mistral/+spec/mistral-execution-origin.
>>
>> To summarize what it’s about: imagine that we have a workflow which
>> calls other workflows and those workflows call some workflows again,
>> etc. etc. In other words, we have a tree of workflows. Right now there
>> isn’t a convenient way to track down the whole execution tree in CLI.
>> For example, see a running workflow but I have no idea whether it was
>> started by user manually or called by another (parent) workflow. In many
>> cases it’s crucial to know, otherwise it’s really painful if we need to
>> debug something or just figure out the whole picture of what’s going on.
>>
>> What this BP offers is that we have an “origin ID” that would always
>> tell the top level (the highest one) workflow execution since which it
>> all started. This is kind of simple solution though and I thought we
>> could massage this idea a little bit and could come up with something
>> more interesting. For example, could we add a new option (i.e.
>> --detailed or --recursive) for ‘mistral execution-get’ command and if
>> it’s provided then we print out information not only about this wf
>> execution itself but about it’s children as well? The only question is:
>> how do we display a tree in CLI?
>>
>> I also created an empty etherpad where we can sketch out how it could
>> look like:
>> https://etherpad.openstack.org/p/mistral-cli-workflow-execution-tree
>>
>> Any other ideas? Thoughts?
>>
>> Renat Akhmerov
>> @ Mirantis Inc.
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
*Regards!*
*-----------------------------------*
*Lingxian Kong*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150902/0c9d3433/attachment.html>