[openstack-dev] [Mistral] Changing "expression" delimiters in Mistral DSL

Anastasia Kuznetsova akuznetsova at mirantis.com
Tue Feb 17 16:28:27 UTC 2015


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.

I am not sure that similarity with something should be one of the main
criteria, because we don't know who will use Mistral.

I like:
- <{1 + $.var}> Renat's example
- variant with using some functions (item 2 in Dmitry's list):  { yaql:
“1+1+$.my.var < 100” } or <yaql: 'Hello' + $.name >
- my two cents, maybe we can use something like: result: -< "Hello" +
$.name >-


Regards,
Anastasia Kuznetsova

On Tue, Feb 17, 2015 at 1:17 PM, Nikolay Makhotkin <nmakhotkin at mirantis.com>
wrote:

> Some suggestions from me:
>
> 1. <y 1 + $.var > # (short from yaql).
> 2. <{ 1 + $.var }>  # as for me, looks more elegant than <% %>. And
> visually it is more strong
>
> A also like p7 and p8 suggested by Renat.
>
> On Tue, Feb 17, 2015 at 11:43 AM, Renat Akhmerov <rakhmerov at mirantis.com>
> wrote:
>
>> One more:
>>
>> p9: \{1 + $.var} # That’s pretty much what
>> https://review.openstack.org/#/c/155348/ 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
>>
>>
>>
>> Renat Akhmerov
>> @ Mirantis Inc.
>>
>>
>>
>> On 17 Feb 2015, at 13:37, Renat Akhmerov <rakhmerov at mirantis.com> wrote:
>>
>> Along with <% %> syntax here are some other alternatives that I checked
>> for YAML friendliness with my short comments:
>>
>> p1: ${1 + $.var}     # Here it’s bad that $ sign is used for two
>> different things
>> p2: ~{1 + $.var}     # ~ is easy to miss in a text
>> p3: ^{1 + $.var}     # For someone may be associated with regular
>> expressions
>> p4: ?{1 + $.var}
>> p5: <{1 + $.var}> # This is kinda crazy
>> p6: e{1 + $.var} # That looks a pretty interesting option to me, “e”
>> could mean “expression” here.
>> p7: yaql{1 + $.var} # 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
>> p8: y{1 + $.var} # “y” here is just shortened “yaql"
>>
>>
>> Any ideas and thoughts would be really appreciated!
>>
>> Renat Akhmerov
>> @ Mirantis Inc.
>>
>>
>>
>> On 17 Feb 2015, at 12:53, Renat Akhmerov <rakhmerov at mirantis.com> wrote:
>>
>> Dmitri,
>>
>> 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).
>>
>> Just a general note about all changes happening now: *Once we release
>> kilo stable release our API, DSL of version 2 must be 100% stable*. 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.
>>
>> 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.
>>
>> I would be good if we could here more feedback on this, especially from
>> people who started using Mistral.
>>
>> Thanks
>>
>> Renat Akhmerov
>> @ Mirantis Inc.
>>
>>
>>
>> On 17 Feb 2015, at 03:06, Dmitri Zimine <dzimine at stackstorm.com> wrote:
>>
>> SUMMARY:
>> ----------------
>>
>> We are changing the syntax for inlining YAQL expressions in Mistral YAML
>> from {1+$.my.var} (or “{1+$.my.var}”) to <% 1+$.my.var %>
>>
>> Below I explain the rationale and the criteria for the choice. Comments
>> and suggestions welcome.
>>
>> DETAILS:
>> -------------
>>
>> 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:
>>
>>     publish:
>>        intvalue1: "{1+1}” # Confusing: you expect quotes to be string.
>>        intvalue2: "{int(1+1)}” # Even this doestn’ clean the confusion
>>        whatisthis:"{$.x + $.y}” # What type would this return?
>>
>> We got a very strong push back from users in the filed on this syntax.
>>
>> 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.
>>
>> Criteria for selecting best alternative are:
>> 1) Consistently applies to to all cases of using YAML in DSL
>> 2) Complies with YAML
>> 3) Familiar to target user audience - openstack and devops
>>
>> We prefer using two-char delimiters to avoid requiring extra escaping
>> within the expressions.
>>
>> 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]):
>>
>> ALTERNATIVES considered:
>> --------------------------------------------------
>>
>> 1) Use Ansible-like syntax:
>> http://docs.ansible.com/YAMLSyntax.html#gotchas
>> Rejected for confusion around types. See above.
>>
>> 2) Use functions, like Heat HOT or TOSCA:
>>
>> 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:
>>
>>     publish:
>>      - bool_var: { yaql: “1+1+$.my.var < 100” }
>>
>> Not bad, but currently rejected as it reads worse than delimiter-based
>> syntax, especially in simplified one-line action invocation.
>>
>> 3) < > paired with other symbols: php-styoe  <? ..?>
>>
>>
>> *REFERENCES: *
>> ----------------------
>>
>> [1] Allow arbitrary YAQL expressions, not just ones started with $ :
>> https://github.com/stackforge/mistral/commit/5c10fb4b773cd60d81ed93aec33345c0bf8f58fd
>> [2] Use Ansible-like syntax to make YAQL expressions YAML complient
>> https://github.com/stackforge/mistral/commit/d9517333b1fc9697d4847df33d3b774f881a111b
>> [3] Preserving types in YAQL
>> https://github.com/stackforge/mistral/blob/d9517333b1fc9697d4847df33d3b774f881a111b/mistral/tests/unit/test_expressions.py#L152-L184
>> [4]Using <% %> in Puppet
>> https://docs.puppetlabs.com/guides/templating.html#erb-is-plain-text-with-embedded-ruby
>>
>> [5] Etherpad with discussion
>> https://etherpad.openstack.org/p/mistral-YAQL-delimiters
>> [6] Blueprint
>> https://blueprints.launchpad.net/mistral/+spec/yaql-delimiters
>>
>>
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best Regards,
> Nikolay
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150217/f3b4cb59/attachment.html>


More information about the OpenStack-dev mailing list