Open Stack

Winson, Lakshmi, Renat: 

It looked good and I began to write down the summary: 
https://etherpad.openstack.org/p/mistral-global-context

But than realized that it’s not safe to assume from the action, that the global context will be supplied as part of API call. 
Check it out in the etherpad.

What problems are we trying to solve: 
1) reduce passing the same parameters over and over from parent to child
2) “automatically” make a parameter accessible to most actions without typing it all over (like auth token) 

Can #1 be solved by passing input to subworkflows automatically
Can #2 be solved somehow else? Default passing of arbitrary parameters to action seems like breaking abstraction.

Thoughts? need to brainstorm further….

DZ> 


On Dec 12, 2014, at 12:54 PM, W Chan <m4d.coder at gmail.com> wrote:

> Renat, Dmitri,
> 
> On supplying the global context into the workflow execution...
> 
> In addition to Renat's proposal, I have a few here.
> 
> 1) Pass them implicitly in start_workflow as another kwargs in the **params.  But on thinking, we should probably make global context explicitly defined in the WF spec.  Passing them implicitly may be hard to follow during troubleshooting where the value comes from by looking at the WF spec.  Plus there will be cases where WF authors want it explicitly defined. Still debating here...
> 
> inputs = {...}
> globals = {...}
> start_workflow('my_workflow', inputs, globals=globals)
> 
> 2) Instead of adding to the WF spec, what if we change the scope in existing input params?  For example, inputs defined in the top workflow by default is visible to all subflows (pass down to workflow task on run_workflow) and tasks (passed to action on execution).
> 
> 3) Add to the WF spec
> 
> workflow:
>     type: direct
>     global:
>         - global1
>         - global2
>     input:
>         - input1
>         - input2
> 
> Winson
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141212/683a150e/attachment.html>