Open Stack

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 scopes:

* local - default scope, only current workflow tasks can see it
* global - all entities can see it: this workflow itself (its tasks), its nested workflows and actions
* workflow - only this workflow and actions called from this workflow can see it

However, if we follow that path we would need to change how Mistral validates workflow input parameters. Currently, if we pass something into workflow it must be declared as an input parameter. In case of “global” scope and nested workflows this mechanism is too primitive because a nested workflow may get something that it doesn’t expect. So it may not be that straightforward.

Thoughts?

Just in case, I’ll repeat related BPs from another thread:

* https://blueprints.launchpad.net/mistral/+spec/mistral-execution-environment <https://blueprints.launchpad.net/mistral/+spec/mistral-execution-environment>
* https://blueprints.launchpad.net/mistral/+spec/mistral-global-context <https://blueprints.launchpad.net/mistral/+spec/mistral-global-context>
* https://blueprints.launchpad.net/mistral/+spec/mistral-workflow-constants <https://blueprints.launchpad.net/mistral/+spec/mistral-workflow-constants>
* https://blueprints.launchpad.net/mistral/+spec/mistral-default-input-values <https://blueprints.launchpad.net/mistral/+spec/mistral-default-input-values>

Renat Akhmerov
@ Mirantis Inc.



> On 10 Dec 2014, at 13:12, W Chan <m4d.coder at gmail.com> wrote:
> 
> 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 contextual information about this specific workflow execution (i.e. a reference to a record in an external system related such as a service ticket ID or CMDB record ID).  The values do not necessary carry across multiple executions.  But as I understand, the execution environment configuration is a set of reusable configuration that can be shared across multiple workflow executions.  The fact where action parameters are specified explicitly over and over again is a common problem in the DSL.
> 
> 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/20141210/5bd844ac/attachment.html>