One more:

p9: \{1 + $.var}        # That’s pretty much what 
https://review.openstack.org/#/c/155348/ 
<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 <rakhme...@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 <rakhme...@mirantis.com 
>> <mailto:rakhme...@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 <dzim...@stackstorm.com 
>>> <mailto:dzim...@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 
>>> <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
>>>  
>>> <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
>>>  
>>> <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
>>>  
>>> <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
>>>  
>>> <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 
>>> <https://etherpad.openstack.org/p/mistral-YAQL-delimiters>
>>> [6] Blueprint 
>>> https://blueprints.launchpad.net/mistral/+spec/yaql-delimiters 
>>> <https://blueprints.launchpad.net/mistral/+spec/yaql-delimiters>
>>> 
>> 
> 

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to