> 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 and over from parent to child
> 2) “automatically” make a parameter accessible to most actions without typing 
> it all over (like auth token) 

I agree that it’s one of the angle from what we’re looking at the problem. 
However, IMO, it’s wider than just these two points. My perspective is that we 
are, first of all, discussing workflow variables’ scoping (see my previous 
email in this thread). So I would rather focus on that. Let’s list all the 
scopes that would make sense, their semantics and use cases where each of them 
could solve particular usability problems (I’m saying “usability problems” 
because it’s really all about usability only).

The reason I’m trying to discuss all this from this point of view is because I 
think we should try to be more formal on things like that. 

> Can #1 be solved by passing input to subworkflows automatically

No, it can’t. “input” is something that gets validated upon workflow execution 
(which happens now) and can’t be arbitrarily passed all the way through because 
of that. If we introduce something like “global” scope then we can always pass 
variables of this scope down to nested workflows using a separate mechanism 
(i.e. different parameter of start_workflow() method). 

> Can #2 be solved somehow else? Default passing of arbitrary parameters to 
> action seems like breaking abstraction

Yes, unless explicitly specified I would not give actions more than they need. 
Encapsulation has been proven to be a good thing.

> Thoughts? need to brainstorm further….

Just once again, I appeal to talk about scopes, their semantics and use cases 
purely from workflow language (DSL) and API standpoint because I’m afraid 
otherwise we could bury ourselves under a pile of minor technical details. 
Specification first, implementation second.


Renat Akhmerov
@ Mirantis Inc.

OpenStack-dev mailing list

Reply via email to