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 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. Thanks Renat Akhmerov @ Mirantis Inc.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
