<div dir="ltr">Out of those three I still prefer <% %>. The main reason I like it is familiarity. Also the question mark makes me think of a wildcard, and I don't want to use curly braces because of all the aforementioned reasons (already has a meaning in YAML).<div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 18, 2015 at 3:07 PM, Dmitri Zimine <span dir="ltr"><<a href="mailto:dzimine@stackstorm.com" target="_blank">dzimine@stackstorm.com</a>></span> wrote:<br><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 style="word-wrap:break-word"><div><blockquote type="cite"><div style="word-wrap:break-word"><div><b>Syntax options that we’d like to discuss </b><b>further </b></div><div><br></div><span><% 1 + 1 %> # pro- ruby/js/puppet/chef familiarity con - spaces, and % is too large symbol<br></span><{1 + 1}> # pro - less spaces, con - no familiarity<span><br><? 1 + 1 ?> # php familiarity, need spaces<br></span><span><br>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><span><br></span></div><div><span>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> </div>To me, another critical criteria is familiarity: target users - openstack developers and devops, familiar with the delimiters. <div><br></div><div>That is why of the three above I prefer <% %> . </div><div><br></div><div>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><div><div><br></div><div><br></div><div>[1] <a href="https://docs.puppetlabs.com/guides/templating.html#erb-is-plain-text-with-embedded-ruby" style="font-family:'Helvetica Neue';font-size:13px" target="_blank">https://docs.puppetlabs.com/guides/templating.html#erb-is-plain-text-with-embedded-ruby</a> </div><div><br></div><div><br></div><div>On Feb 18, 2015, at 3:20 AM, Renat Akhmerov <<a href="mailto:rakhmerov@mirantis.com" target="_blank">rakhmerov@mirantis.com</a>> wrote:</div><br><blockquote type="cite"><div style="word-wrap:break-word"><div>Hi again,</div><div><br></div><div>Sorry, I started writing this email before Angus replied so I will shoot it as is and then we can continue…</div><div><br></div><div><br></div><div>So after discussing all the options again with a small group of team members we came to the following things:</div><div><br></div><div><b>Syntax options that we’d like to discuss </b><b>further </b></div><div><br></div><span><% 1 + 1 %> # pro- ruby/js/puppet/chef familiarity con - spaces, and % is too large symbol<br></span><{1 + 1}> # pro - less spaces, con - no familiarity<span><br><? 1 + 1 ?> # php familiarity, need spaces<br></span><span><br>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><span><br></span></div><div><span>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><span><br>Some additional details can be found in [0]<br><br></span><span><br></span><span>[0] </span><a href="https://etherpad.openstack.org/p/mistral-YAQL-delimiters" target="_blank">https://etherpad.openstack.org/p/mistral-YAQL-delimiters</a><div><span class=""><br><div>
<div>Renat Akhmerov</div><div>@ Mirantis Inc.</div><div><br></div>
</div>
<br></span><div><div class="h5"><div><blockquote type="cite"><div>On 18 Feb 2015, at 07:37, Patrick Hoolboom <<a href="mailto:patrick@stackstorm.com" target="_blank">patrick@stackstorm.com</a>> wrote:</div><br><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> 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 style="word-wrap:break-word"><div><br><blockquote type="cite"><div style="margin:0px"><span style="font-family:Helvetica"><b>From: </b></span><span style="font-family:Helvetica">Anastasia Kuznetsova <<a href="mailto:akuznetsova@mirantis.com" target="_blank">akuznetsova@mirantis.com</a>><br></span></div><div style="margin:0px"><span style="font-family:Helvetica"><b>Subject: </b></span><span style="font-family:Helvetica"><b>Re: [openstack-dev] [Mistral] Changing "expression" delimiters in Mistral DSL</b><br></span></div><div style="margin:0px"><span style="font-family:Helvetica"><b>Date: </b></span><span style="font-family:Helvetica">February 17, 2015 at 8:28:27 AM PST<br></span></div><div style="margin:0px"><span style="font-family:Helvetica"><b>To: </b></span><span style="font-family:Helvetica">"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br></span></div><div style="margin:0px"><span style="font-family:Helvetica"><b>Reply-To: </b></span><span style="font-family:Helvetica">"OpenStack Development Mailing List \(not for usage questions\)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br></span></div><br><div><div dir="ltr"><div>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><br></div><div>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><br></div><div>I like:</div><div>- <{1 + $.var}> Renat's example </div><div>- variant with using some functions (item 2 in Dmitry's list): { yaql: “1+1+$.my.var < 100” } or <yaql: 'Hello' + $.name ></div><div>- my two cents, maybe we can use something like: result: -< "Hello" + $.name >-</div><div><br></div><div><br></div><div>Regards,<br>Anastasia Kuznetsova</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 17, 2015 at 1:17 PM, Nikolay Makhotkin <span dir="ltr"><<a href="mailto:nmakhotkin@mirantis.com" target="_blank">nmakhotkin@mirantis.com</a>></span> wrote:<br><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">Some suggestions from me: <br><br>1. <y 1 + $.var > # (short from yaql).<div>2. <{ 1 + $.var }> # as for me, looks more elegant than <% %>. And visually it is more strong<br><br>A also like p7 and p8 suggested by Renat.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Tue, Feb 17, 2015 at 11:43 AM, Renat Akhmerov <span dir="ltr"><<a href="mailto:rakhmerov@mirantis.com" target="_blank">rakhmerov@mirantis.com</a>></span> wrote:<br></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"><div><div><div style="word-wrap:break-word">One more:<div><br></div><div>p9: \{1 + $.var}<span style="white-space:pre-wrap"> </span># That’s pretty much what <a href="https://review.openstack.org/#/c/155348/" target="_blank">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><br></div><div><br></div><div><span><br><div>
<div>Renat Akhmerov</div><div>@ Mirantis Inc.</div><div><br></div><br>
</div>
<br></span><div><div><blockquote type="cite"><div>On 17 Feb 2015, at 13:37, Renat Akhmerov <<a href="mailto:rakhmerov@mirantis.com" target="_blank">rakhmerov@mirantis.com</a>> wrote:</div><br><div><div style="word-wrap:break-word">Along with <% %> syntax here are some other alternatives that I checked for YAML friendliness with my short comments:<div><br></div><div><div>p1: ${1 + $.var} <span style="white-space:pre-wrap"> </span># Here it’s bad that $ sign is used for two different things</div><div>p2: ~{1 + $.var} <span style="white-space:pre-wrap"> </span># ~ is easy to miss in a text</div><div>p3: ^{1 + $.var} <span style="white-space:pre-wrap"> </span># For someone may be associated with regular expressions</div><div>p4: ?{1 + $.var}<span style="white-space:pre-wrap"> </span></div><div>p5: <{1 + $.var}><span style="white-space:pre-wrap"> </span># This is kinda crazy</div><div>p6: e{1 + $.var}<span style="white-space:pre-wrap"> </span># That looks a pretty interesting option to me, “e” could mean “expression” here.</div><div>p7: yaql{1 + $.var}<span 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>p8: y{1 + $.var}<span style="white-space:pre-wrap"> </span># “y” here is just shortened “yaql"</div><div><br></div><div><br></div><div>Any ideas and thoughts would be really appreciated!</div><div><br></div><div>
<div>Renat Akhmerov</div><div>@ Mirantis Inc.</div><div><br></div><br>
</div>
<br><div><blockquote type="cite"><div>On 17 Feb 2015, at 12:53, Renat Akhmerov <<a href="mailto:rakhmerov@mirantis.com" target="_blank">rakhmerov@mirantis.com</a>> wrote:</div><br><div><div style="word-wrap:break-word">Dmitri,<div><br></div><div>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><br></div><div>Just a general note about all changes happening now: <b>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><br></div><div>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><br></div><div>I would be good if we could here more feedback on this, especially from people who started using Mistral.</div><div><br></div><div>Thanks</div><div><br><div>
<div>Renat Akhmerov</div><div>@ Mirantis Inc.</div><div><br></div><br>
</div>
<br><div><blockquote type="cite"><div>On 17 Feb 2015, at 03:06, Dmitri Zimine <<a href="mailto:dzimine@stackstorm.com" target="_blank">dzimine@stackstorm.com</a>> wrote:</div><br><div><div style="word-wrap:break-word"><div>SUMMARY: </div><div>----------------</div><div><br></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><br></div><div>Below I explain the rationale and the criteria for the choice. Comments and suggestions welcome.</div><div><div><br></div><div>DETAILS: </div><div>-------------</div><div><br></div><div>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><br></div><div> publish:<br> intvalue1: "{1+1}” # Confusing: you expect quotes to be string.<br> intvalue2: "{int(1+1)}” # Even this doestn’ clean the confusion<br> whatisthis:"{$.x + $.y}” # What type would this return? </div><div><br></div><div>We got a very strong push back from users in the filed on this syntax. </div><div><br></div><div>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><br></div><div><div>Criteria for selecting best alternative are: </div><div>1) Consistently applies to to all cases of using YAML in DSL</div><div>2) Complies with YAML </div><div>3) Familiar to target user audience - openstack and devops</div></div><div><br></div><div>We prefer using two-char delimiters to avoid requiring extra escaping within the expressions.</div><div><br></div><div>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><br></div><div><div>ALTERNATIVES considered:</div><div>--------------------------------------------------</div><div><br></div><div>1) Use Ansible-like syntax: <a href="http://docs.ansible.com/YAMLSyntax.html#gotchas" target="_blank">http://docs.ansible.com/YAMLSyntax.html#gotchas</a></div><div>Rejected for confusion around types. See above.</div><div><br></div><div>2) Use functions, like Heat HOT or TOSCA:</div><div><br></div><div>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><br></div><div> publish:</div><div> - bool_var: { yaql: “1+1+$.my.var < 100” } </div><div><br></div><div>Not bad, but currently rejected as it reads worse than delimiter-based syntax, especially in simplified one-line action invocation.</div><div><br></div><div>3) < > paired with other symbols: php-styoe <? ..?></div><div><br></div></div><div><br></div><div><b>REFERENCES: </b></div><div>----------------------</div><div><br></div><div>[1] Allow arbitrary YAQL expressions, not just ones started with $ : <a href="https://github.com/stackforge/mistral/commit/5c10fb4b773cd60d81ed93aec33345c0bf8f58fd" target="_blank">https://github.com/stackforge/mistral/commit/5c10fb4b773cd60d81ed93aec33345c0bf8f58fd</a></div><div>[2] Use Ansible-like syntax to make YAQL expressions YAML complient <a href="https://github.com/stackforge/mistral/commit/d9517333b1fc9697d4847df33d3b774f881a111b" target="_blank">https://github.com/stackforge/mistral/commit/d9517333b1fc9697d4847df33d3b774f881a111b</a></div><div>[3] Preserving types in YAQL <a href="https://github.com/stackforge/mistral/blob/d9517333b1fc9697d4847df33d3b774f881a111b/mistral/tests/unit/test_expressions.py#L152-L184" target="_blank">https://github.com/stackforge/mistral/blob/d9517333b1fc9697d4847df33d3b774f881a111b/mistral/tests/unit/test_expressions.py#L152-L184</a></div><div>[4]Using <% %> in Puppet <a href="https://docs.puppetlabs.com/guides/templating.html#erb-is-plain-text-with-embedded-ruby" style="font-family:'Helvetica Neue';font-size:13px" target="_blank">https://docs.puppetlabs.com/guides/templating.html#erb-is-plain-text-with-embedded-ruby</a> </div><div>[5] Etherpad with discussion <a href="https://etherpad.openstack.org/p/mistral-YAQL-delimiters" target="_blank">https://etherpad.openstack.org/p/mistral-YAQL-delimiters</a></div><div>[6] Blueprint <a href="https://blueprints.launchpad.net/mistral/+spec/yaql-delimiters" target="_blank">https://blueprints.launchpad.net/mistral/+spec/yaql-delimiters</a></div></div><div><br></div></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></div><br></div></div>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><font>Best Regards,</font></div><div><font>Nikolay</font></div></div></div>
</font></span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div></blockquote></div><br></div></blockquote></div><br></div></div>
__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div></blockquote></div><br></div></div></div></div></div><div><div class="h5">__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div></div></blockquote></div><br></div></div></blockquote></div><br></div></div>