<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Winson, ok, I got the idea.<div class=""><br class=""></div><div class="">Just a crazy idea that came to my mind. What if we just mark some of the input parameters as “global”? For example,</div><div class=""><br class=""></div><div class="">wf:</div><div class=""> type: direct</div><div class=""> input:</div><div class=""> - param1</div><div class=""> - param2: global</div><div class=""><br class=""></div><div class="">One way or another we’re talking about different scopes. I see the following possible scopes:</div><div class=""><br class=""></div><div class="">* local - default scope, only current workflow tasks can see it</div><div class="">* global - all entities can see it: this workflow itself (its tasks), its nested workflows and actions</div><div class="">* workflow - only this workflow and actions called from this workflow can see it</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Thoughts?</div><div class=""><br class=""></div><div class="">Just in case, I’ll repeat related BPs from another thread:</div><div class=""><br class=""></div><div class="">* <a href="https://blueprints.launchpad.net/mistral/+spec/mistral-execution-environment" class="">https://blueprints.launchpad.net/mistral/+spec/mistral-execution-environment</a></div><div class="">* <a href="https://blueprints.launchpad.net/mistral/+spec/mistral-global-context" class="">https://blueprints.launchpad.net/mistral/+spec/mistral-global-context</a></div><div class="">* <a href="https://blueprints.launchpad.net/mistral/+spec/mistral-workflow-constants" class="">https://blueprints.launchpad.net/mistral/+spec/mistral-workflow-constants</a></div><div class="">* <a href="https://blueprints.launchpad.net/mistral/+spec/mistral-default-input-values" class="">https://blueprints.launchpad.net/mistral/+spec/mistral-default-input-values</a></div><div class=""><br class=""></div><div class=""><div class="">
<div class="">Renat Akhmerov</div><div class="">@ Mirantis Inc.</div><div class=""><br class=""></div><br class="Apple-interchange-newline">
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 10 Dec 2014, at 13:12, W Chan <<a href="mailto:m4d.coder@gmail.com" class="">m4d.coder@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Nikolay,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Winson<br class=""></div><div class=""><br class=""></div></div>
_______________________________________________<br class="">OpenStack-dev mailing list<br class=""><a href="mailto:OpenStack-dev@lists.openstack.org" class="">OpenStack-dev@lists.openstack.org</a><br class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br class=""></div></blockquote></div><br class=""></div></body></html>