<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="">Guys,<div class=""><br class=""></div><div class="">I really appreciate the input of you all.</div><div class=""><br class=""></div><div class="">We decided that ideally we need to agree on that syntax within days, not weeks or months. But anyway, since we started this discussion yesterday I just want to give us extra 1-2 days to play with all these thoughts in our heads.</div><div class=""><br class=""></div><div class="">Just one additional maybe a little bit crazy idea to the pile we’ve already made:</div><div class="">What if we officially allow more than one delimiter syntax? Why stick to just one? Technically I’m 99% sure it’s doable. As long as it’s clearly pointed in the documentation there shouldn’t problems with understanding. Just one con (IMO, little) that I see here is “if so then what syntax do we use to write all our examples, docs, tutorials etc. etc.”</div><div class=""><br class=""></div><div class="">So obviously one of the options (just for majority of votes) would be <% %> and something else less familiar but more smoother looking in YAML such as yaql{…} or <{…}>.</div><div class=""><br class=""></div><div class="">I’m ready to be beaten by stones! Fire away :)</div><div class=""><br 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 19 Feb 2015, at 11:25, James Fryman <<a href="mailto:james@stackstorm.com" class="">james@stackstorm.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">On Feb 18, 2015, at 3:07 PM, Dmitri Zimine <<a href="mailto:dzimine@stackstorm.com" class="">dzimine@stackstorm.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><b class="">Syntax options that we’d like to discuss </b><b class="">further </b></div><div class=""><br class=""></div><span class=""><% 1 + 1 %> # pro- ruby/js/puppet/chef familiarity con - spaces, and % is too large symbol<br class=""></span><{1 + 1}> # pro - less spaces, con - no familiarity<span class=""><br class=""><? 1 + 1 ?> # php familiarity, need spaces<br class=""></span><span class=""><br class="">The primary criteria to select these 3 options is that they are YAML compatible. Technically they all would solve our problems (primarily no embracing quotes needed like in Ansible so no ambiguity on data types).</span><div class=""><span class=""><br class=""></span></div><div class=""><span class="">The secondary criteria is syntax symmetry. After all I agree with Patrick's point about better readability when we have opening and closing sequences alike.</span></div></div></blockquote></div><div class=""> </div>To me, another critical criteria is familiarity: target users - openstack developers and devops, familiar with the delimiters. <div class=""><br class=""></div><div class="">That is why of the three above I prefer <% %> . </div><div class=""><br class=""></div><div class="">It is commonly used in Puppet/Chef [1], Ruby, Javascript. One won’t be surprised to see it and won’t need to change the muscle memory to type open/closed characters especially when working on say Puppet and Mistral at the same time (not unlikely). </div><div class=""><div class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class="">[1] <a href="https://docs.puppetlabs.com/guides/templating.html#erb-is-plain-text-with-embedded-ruby" target="_blank" class="" style="font-family: 'Helvetica Neue'; font-size: 13px;">https://docs.puppetlabs.com/guides/templating.html#erb-is-plain-text-with-embedded-ruby</a> </div><div class=""><br class=""></div></div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">I have been lurking on this thread, and just wanted to toss in $0.02 as you all deliberate. In truth, any of the options Renat highlights would be fine, and the points made to arrive at the final choices are sound. The end result will types will be explicit, and that is great. In light of this though, using the <% %> syntax is still ideal if only for one reason: friction. </span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">In a recent discussion with a colleague of mine, he told me that in his daily job, he is so busy and slammed with operations tasks, his measure of a tool he will use is whether it provides value within 30-60 minutes. Otherwise, there is a fire somewhere else that needs to be put out and cannot be bothered.</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">To be frank, there is no way that this proposed syntax change and how it is ultimately decorated is going to be a game changer to how future users will evaluate Mistral. But, <a href="x-apple-data-detectors://4" x-apple-data-detectors="true" x-apple-data-detectors-type="calendar-event" x-apple-data-detectors-result="4" class="">at 3am</a> in the morning during a production outage where an Ops admin is hotpatching a workflow to get things moving again... That disparity does in fact matter. Eyes are already trained to look for <% %>, the large amount of spacing draws the eyes, and it's a known function in other existing ops toolkits. Less friction to adoption/less friction to troubleshoot.I think these are all pluses. I want to be drawn to where things are changing or dynamic in my templates to aid in troubleshooting. </span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Again, this is just another data point to throw out. While users are busy trying to absorb all that is workflow creation/design... Having as many likenesses and anchors to existing tools can certainly not hurt adoption. </span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Thank you all for your efforts!</span></div></div><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">On Feb 18, 2015, at 3:20 AM, Renat Akhmerov <<a href="mailto:rakhmerov@mirantis.com" class="">rakhmerov@mirantis.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">Hi again,</div><div class=""><br class=""></div><div class="">Sorry, I started writing this email before Angus replied so I will shoot it as is and then we can continue…</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">So after discussing all the options again with a small group of team members we came to the following things:</div><div class=""><br class=""></div><div class=""><b class="">Syntax options that we’d like to discuss </b><b class="">further </b></div><div class=""><br class=""></div><span class=""><% 1 + 1 %> # pro- ruby/js/puppet/chef familiarity con - spaces, and % is too large symbol<br class=""></span><{1 + 1}> # pro - less spaces, con - no familiarity<span class=""><br class=""><? 1 + 1 ?> # php familiarity, need spaces<br class=""></span><span class=""><br class="">The primary criteria to select these 3 options is that they are YAML compatible. Technically they all would solve our problems (primarily no embracing quotes needed like in Ansible so no ambiguity on data types).</span><div class=""><span class=""><br class=""></span></div><div class=""><span class="">The secondary criteria is syntax symmetry. After all I agree with Patrick's point about better readability when we have opening and closing sequences alike.</span></div><div class=""><span class=""><br class="">Some additional details can be found in [0]<br class=""><br class=""></span><span class=""><br class=""></span><span class="">[0] </span><a href="https://etherpad.openstack.org/p/mistral-YAQL-delimiters" class="">https://etherpad.openstack.org/p/mistral-YAQL-delimiters</a><div class=""><br class=""><div apple-content-edited="true" class=""><div class="">Renat Akhmerov</div><div class="">@ Mirantis Inc.</div><div class=""><br class=""></div></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 18 Feb 2015, at 07:37, Patrick Hoolboom <<a href="mailto:patrick@stackstorm.com" class="">patrick@stackstorm.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> My main concern with the {} delimiters in YAQL is that the curly brace already has a defined use within YAML. We most definitely will eventually run in to parsing errors with whatever delimiter we choose but I don't feel that it should conflict with the markup language it is directly embedded in. It gets quite difficult to, at a glance, identify YAQL expressions. <% %> may appear ugly to some but I feel that it works as a clear delimiter of both the beginning AND the end of the YAQL query. The options that only escape the beginning look fine in small examples like this but the workflows that we have written or seen in the wild tend to have some fairly large expressions. If the opening and closing delimiters don't match, it gets quite difficult to read. </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class=""><br class=""><blockquote type="cite" class=""><div class="" style="margin: 0px;"><span class="" style="font-family: Helvetica;"><b class="">From:<span class="Apple-converted-space"> </span></b></span><span class="" style="font-family: Helvetica;">Anastasia Kuznetsova <<a href="mailto:akuznetsova@mirantis.com" target="_blank" class="">akuznetsova@mirantis.com</a>><br class=""></span></div><div class="" style="margin: 0px;"><span class="" style="font-family: Helvetica;"><b class="">Subject:<span class="Apple-converted-space"> </span></b></span><span class="" style="font-family: Helvetica;"><b class="">Re: [openstack-dev] [Mistral] Changing "expression" delimiters in Mistral DSL</b><br class=""></span></div><div class="" style="margin: 0px;"><span class="" style="font-family: Helvetica;"><b class="">Date:<span class="Apple-converted-space"> </span></b></span><span class="" style="font-family: Helvetica;">February 17, 2015 at 8:28:27 AM PST<br class=""></span></div><div class="" style="margin: 0px;"><span class="" style="font-family: Helvetica;"><b class="">To:<span class="Apple-converted-space"> </span></b></span><span class="" style="font-family: Helvetica;">"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank" class="">openstack-dev@lists.openstack.org</a>><br class=""></span></div><div class="" style="margin: 0px;"><span class="" style="font-family: Helvetica;"><b class="">Reply-To:<span class="Apple-converted-space"> </span></b></span><span class="" style="font-family: Helvetica;">"OpenStack Development Mailing List \(not for usage questions\)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank" class="">openstack-dev@lists.openstack.org</a>><br class=""></span></div><br class=""><div class=""><div dir="ltr" class=""><div class="">As for me, I think that <% ... %> is not an elegant solution and looks massive because of '%' sign. Also I agree with Renat, that <% ... %> reminds HTML/Jinja2 syntax. </div><div class=""><br class=""></div><div class="">I am not sure that similarity with something should be one of the main criteria, because we don't know who will use Mistral.</div><div class=""><br class=""></div><div class="">I like:</div><div class="">- <{1 + $.var}> Renat's example </div><div class="">- variant with using some functions (item 2 in Dmitry's list): { yaql: “1+1+$.my.var < 100” } or <yaql: 'Hello' + $.name ></div><div class="">- my two cents, maybe we can use something like: result: -< "Hello" + $.name >-</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Regards,<br class="">Anastasia Kuznetsova</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Feb 17, 2015 at 1:17 PM, Nikolay Makhotkin<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:nmakhotkin@mirantis.com" target="_blank" class="">nmakhotkin@mirantis.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class="">Some suggestions from me: <br class=""><br class="">1. <y 1 + $.var > # (short from yaql).<div class="">2. <{ 1 + $.var }> # as for me, looks more elegant than <% %>. And visually it is more strong<br class=""><br class="">A also like p7 and p8 suggested by Renat.<br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote"><div class=""><div class="">On Tue, Feb 17, 2015 at 11:43 AM, Renat Akhmerov<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:rakhmerov@mirantis.com" target="_blank" class="">rakhmerov@mirantis.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""></div></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;"><div class=""><div class=""><div class="" style="word-wrap: break-word;">One more:<div class=""><br class=""></div><div class="">p9: \{1 + $.var}<span class="" style="white-space: pre-wrap;"> </span># That’s pretty much what <a href="https://review.openstack.org/#/c/155348/" target="_blank" class="">https://review.openstack.org/#/c/155348/</a> addresses but it’s not exactly that. Note that we don’t have to put it in quotes in this case to deal with YAML {} semantics, it’s just a string</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><span class=""><br class=""><div class=""><div class="">Renat Akhmerov</div><div class="">@ Mirantis Inc.</div><div class=""><br class=""></div><br class=""></div><br class=""></span><div class=""><div class=""><blockquote type="cite" class=""><div class="">On 17 Feb 2015, at 13:37, Renat Akhmerov <<a href="mailto:rakhmerov@mirantis.com" target="_blank" class="">rakhmerov@mirantis.com</a>> wrote:</div><br class=""><div class=""><div class="" style="word-wrap: break-word;">Along with <% %> syntax here are some other alternatives that I checked for YAML friendliness with my short comments:<div class=""><br class=""></div><div class=""><div class="">p1: ${1 + $.var} <span class="" style="white-space: pre-wrap;"> </span># Here it’s bad that $ sign is used for two different things</div><div class="">p2: ~{1 + $.var} <span class="" style="white-space: pre-wrap;"> </span># ~ is easy to miss in a text</div><div class="">p3: ^{1 + $.var} <span class="" style="white-space: pre-wrap;"> </span># For someone may be associated with regular expressions</div><div class="">p4: ?{1 + $.var}<span class="" style="white-space: pre-wrap;"> </span></div><div class="">p5: <{1 + $.var}><span class="" style="white-space: pre-wrap;"> </span># This is kinda crazy</div><div class="">p6: e{1 + $.var}<span class="" style="white-space: pre-wrap;"> </span># That looks a pretty interesting option to me, “e” could mean “expression” here.</div><div class="">p7: yaql{1 + $.var}<span class="" style="white-space: pre-wrap;"> </span># This is interesting because it would give a clear and easy mechanism to plug in other expression languages, “yaql” here is a used dialect for the following expression</div><div class="">p8: y{1 + $.var}<span class="" style="white-space: pre-wrap;"> </span># “y” here is just shortened “yaql"</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Any ideas and thoughts would be really appreciated!</div><div class=""><br class=""></div><div class=""><div class="">Renat Akhmerov</div><div class="">@ Mirantis Inc.</div><div class=""><br class=""></div><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 17 Feb 2015, at 12:53, Renat Akhmerov <<a href="mailto:rakhmerov@mirantis.com" target="_blank" class="">rakhmerov@mirantis.com</a>> wrote:</div><br class=""><div class=""><div class="" style="word-wrap: break-word;">Dmitri,<div class=""><br class=""></div><div class="">I agree with all your reasonings and fully support the idea of changing the syntax now as well as changing system’s API a little bit due to recently found issues in the current engine design that don’t allow us, for example, to fully implement ‘with-items’ (although that’s a little bit different story).</div><div class=""><br class=""></div><div class="">Just a general note about all changes happening now:<span class="Apple-converted-space"> </span><b class="">Once we release kilo stable release our API, DSL of version 2 must be 100% stable</b>. I was hoping to stabilize it much earlier but the start of production use revealed a number of things (I think this is normal) which we need to address, but not later than the end of Kilo.</div><div class=""><br class=""></div><div class="">As far as <% %> syntax. I see that it would solve a number of problems (YAML friendliness, type ambiguity) but my only not strong argument is that it doesn’t look that elegant in YAML as it looks, for example, in ERB templates. It really reminds me XML/HTML and looks like a bear in a grocery store (tried to make it close to one old russian saying :) ). So just for this only reason I’d suggest we think about other alternatives, maybe not so familiar to Ruby/Chef/Puppet users but looking better with YAML and at the same time being YAML friendly.</div><div class=""><br class=""></div><div class="">I would be good if we could here more feedback on this, especially from people who started using Mistral.</div><div class=""><br class=""></div><div class="">Thanks</div><div class=""><br class=""><div class=""><div class="">Renat Akhmerov</div><div class="">@ Mirantis Inc.</div><div class=""><br class=""></div><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 17 Feb 2015, at 03:06, Dmitri Zimine <<a href="mailto:dzimine@stackstorm.com" target="_blank" class="">dzimine@stackstorm.com</a>> wrote:</div><br class=""><div class=""><div class="" style="word-wrap: break-word;"><div class="">SUMMARY: </div><div class="">----------------</div><div class=""><br class=""></div>We are changing the syntax for inlining YAQL expressions in Mistral YAML from {1+$.my.var} (or “{1+$.my.var}”) to <% 1+$.my.var %><div class=""><br class=""></div><div class="">Below I explain the rationale and the criteria for the choice. Comments and suggestions welcome.</div><div class=""><div class=""><br class=""></div><div class="">DETAILS: </div><div class="">-------------</div><div class=""><br class=""></div><div class="">We faced a number of problems with using YAQL expressions in Mistral DSL: [1] must handle any YAQL, not only the ones started with $; [2] must preserve types and [3] must comply with YAML. We fixed these problems by applying Ansible style syntax, requiring quotes around delimiters (e.g. “{1+$.my.yaql.var}”). However, it lead to unbearable confusion in DSL readability, in regards to types:</div><div class=""><br class=""></div><div class=""> publish:<br class=""> intvalue1: "{1+1}” # Confusing: you expect quotes to be string.<br class=""> intvalue2: "{int(1+1)}” # Even this doestn’ clean the confusion<br class=""> whatisthis:"{$.x + $.y}” # What type would this return? </div><div class=""><br class=""></div><div class="">We got a very strong push back from users in the filed on this syntax. </div><div class=""><br class=""></div><div class="">The crux of the problem is using { } as delimiters YAML. It is plain wrong to use the reserved character. The clean solution is to find a delimiter that won’t conflict with YAML.</div><div class=""><br class=""></div><div class=""><div class="">Criteria for selecting best alternative are: </div><div class="">1) Consistently applies to to all cases of using YAML in DSL</div><div class="">2) Complies with YAML </div><div class="">3) Familiar to target user audience - openstack and devops</div></div><div class=""><br class=""></div><div class="">We prefer using two-char delimiters to avoid requiring extra escaping within the expressions.</div><div class=""><br class=""></div><div class="">The current winner is <% %>. It fits YAML well. It is familiar to openstack/devops as this is used for embedding Ruby expressions in Puppet and Chef (for instance, [4]). It plays relatively well across all cases of using expressions in Mistral (see examples in [5]):</div><div class=""><br class=""></div><div class=""><div class="">ALTERNATIVES considered:</div><div class="">--------------------------------------------------</div><div class=""><br class=""></div><div class="">1) Use Ansible-like syntax:<span class="Apple-converted-space"> </span><a href="http://docs.ansible.com/YAMLSyntax.html#gotchas" target="_blank" class="">http://docs.ansible.com/YAMLSyntax.html#gotchas</a></div><div class="">Rejected for confusion around types. See above.</div><div class=""><br class=""></div><div class="">2) Use functions, like Heat HOT or TOSCA:</div><div class=""><br class=""></div><div class="">HOT templates and TOSCA doesn’t seem to have a concept of typed variables to borrow from (please correct me if I missed it). But they have functions: function: { function_name: {foo: [parameter1, parameter 2], bar:"xxx”}}. Applied to Mistral, it would look like:</div><div class=""><br class=""></div><div class=""> publish:</div><div class=""> - bool_var: { yaql: “1+1+$.my.var < 100” } </div><div class=""><br class=""></div><div class="">Not bad, but currently rejected as it reads worse than delimiter-based syntax, especially in simplified one-line action invocation.</div><div class=""><br class=""></div><div class="">3) < > paired with other symbols: php-styoe <? ..?></div><div class=""><br class=""></div></div><div class=""><br class=""></div><div class=""><b class="">REFERENCES: </b></div><div class="">----------------------</div><div class=""><br class=""></div><div class="">[1] Allow arbitrary YAQL expressions, not just ones started with $ : <a href="https://github.com/stackforge/mistral/commit/5c10fb4b773cd60d81ed93aec33345c0bf8f58fd" target="_blank" class="">https://github.com/stackforge/mistral/commit/5c10fb4b773cd60d81ed93aec33345c0bf8f58fd</a></div><div class="">[2] Use Ansible-like syntax to make YAQL expressions YAML complient <a href="https://github.com/stackforge/mistral/commit/d9517333b1fc9697d4847df33d3b774f881a111b" target="_blank" class="">https://github.com/stackforge/mistral/commit/d9517333b1fc9697d4847df33d3b774f881a111b</a></div><div class="">[3] Preserving types in YAQL <a href="https://github.com/stackforge/mistral/blob/d9517333b1fc9697d4847df33d3b774f881a111b/mistral/tests/unit/test_expressions.py#L152-L184" target="_blank" class="">https://github.com/stackforge/mistral/blob/d9517333b1fc9697d4847df33d3b774f881a111b/mistral/tests/unit/test_expressions.py#L152-L184</a></div><div class="">[4]Using <% %> in Puppet <a href="https://docs.puppetlabs.com/guides/templating.html#erb-is-plain-text-with-embedded-ruby" target="_blank" class="" style="font-family: 'Helvetica Neue'; font-size: 13px;">https://docs.puppetlabs.com/guides/templating.html#erb-is-plain-text-with-embedded-ruby</a> </div><div class="">[5] Etherpad with discussion <a href="https://etherpad.openstack.org/p/mistral-YAQL-delimiters" target="_blank" class="">https://etherpad.openstack.org/p/mistral-YAQL-delimiters</a></div><div class="">[6] Blueprint <a href="https://blueprints.launchpad.net/mistral/+spec/yaql-delimiters" target="_blank" class="">https://blueprints.launchpad.net/mistral/+spec/yaql-delimiters</a></div></div><div class=""><br class=""></div></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></div><br class=""></div></div>__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe:<span class="Apple-converted-space"> </span><a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""><br class=""></blockquote></div><span class=""><font color="#888888" class=""><br class=""><br clear="all" class=""><div class=""><br class=""></div>--<span class="Apple-converted-space"> </span><br class=""><div class=""><div dir="ltr" class=""><div class=""><font class="">Best Regards,</font></div><div class=""><font class="">Nikolay</font></div></div></div></font></span></div><br class="">__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe:<span class="Apple-converted-space"> </span><a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""><br class=""></blockquote></div><br class=""></div>__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe:<span class="Apple-converted-space"> </span><a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></blockquote></div><br class=""></div></blockquote></div><br class=""></div></div>__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe:<span class="Apple-converted-space"> </span><a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></blockquote></div><br class=""></div></div></div>__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe:<span class="Apple-converted-space"> </span><a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></blockquote></div><br class=""></div></div></blockquote><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">__________________________________________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">OpenStack Development Mailing List (not for usage questions)</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span></div></blockquote></div><br class=""></div></body></html>