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,

  type: direct
    - 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.


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


Renat Akhmerov
@ Mirantis Inc.

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

Reply via email to