
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi,<div class=""><div apple-content-edited="true" class=""><br class=""></div><div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=windows-1252" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">It looked good and I began to write down the summary: </div><div class=""><a href="https://etherpad.openstack.org/p/mistral-global-context" class="">https://etherpad.openstack.org/p/mistral-global-context</a></div></div></div></blockquote><div><br class=""></div><div>Thanks, I left my comments in there.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">What problems are we trying to solve: </div><div class="">1) reduce passing the same parameters over and over from parent to child</div><div class="">2) “automatically” make a parameter accessible to most actions without typing it all over (like auth token) </div></div></div></blockquote><div><br class=""></div><div>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).</div><div><br class=""></div><div>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. </div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Can #1 be solved by passing input to subworkflows automatically</div></div></div></blockquote><div><br class=""></div><div>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). </div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Can #2 be solved somehow else? Default passing of arbitrary parameters to action seems like breaking abstraction</div></div></div></blockquote><div><br class=""></div><div>Yes, unless explicitly specified I would not give actions more than they need. Encapsulation has been proven to be a good thing.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Thoughts? need to brainstorm further….</div></div></div></blockquote><br class=""></div><div>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.</div><div><br class=""></div><div>Thanks</div><div><br class=""></div><div><div class="">Renat Akhmerov</div><div class="">@ Mirantis Inc.</div><div class=""><br class=""></div></div><br class=""></div></body></html>