Winson, Lakshmi, Renat: 

It looked good and I began to write down the summary:

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….


On Dec 12, 2014, at 12:54 PM, W Chan <> 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 mailing list

Reply via email to