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