Hi,
It looked good and I began to write down the summary:
https://etherpad.openstack.org/p/mistral-global-context
https://etherpad.openstack.org/p/mistral-global-context
Thanks, I left my comments in there.
What problems are we trying to solve:
1) reduce passing the same parameters over
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
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.
Winson, ok, I got the idea.
Just a crazy idea that came to my mind. What if we just mark some of the input
parameters as “global”? For example,
wf:
type: direct
input:
- param1
- param2: global
One way or another we’re talking about different scopes. I see the following
possible
Nikolay,
Regarding whether the execution environment BP is the same as this global
context BP, I think the difference is in the scope of the variables. The
global context that I'm proposing is provided to the workflow at execution
and is only relevant to this execution. For example, some
