[openstack-dev] [Mistral] RFC - Action spec CLI

Renat Akhmerov rakhmerov at mirantis.com
Thu Dec 18 07:45:05 UTC 2014


> The problem with existing syntax is it is not defined: there is no docs on inlining complex variables [*], and we haven’t tested it for anything more than the simplest cases: https://github.com/stackforge/mistral/blob/master/mistral/tests/unit/workbook/v2/test_dsl_specs_v2.py#L114 <https://github.com/stackforge/mistral/blob/master/mistral/tests/unit/workbook/v2/test_dsl_specs_v2.py#L114>. I will be surprised if anyone figured how to provide a complex object as an inline parameter.

Documentation is really not complete. It’s one of the major problems we’re to fix. It’s just a matter or resources and priorities, as always.

Disagree on testing. We tested it for cases we were interested in. The test you pointed to is not the only one. General comment: If we find that our tests insufficient let’s just go ahead and improve them.

> Do you think regex is the right approach for parsing arbitrary key-values where values is arbitrary json structures? Will it work with something like 
> 	workflow: wf2 object_list=[ {“url”: “http://{$hostname}.example.com <http://example.com/>:8080?x=a&y={$.b}}, 33, null, {{$.key}, [{$.value1}, {$.value2}]}

With regular expressions it just works. As it turns out shlex doesn't. What else? The example you provided is a question of limitations that every convenient thing has. These limitations should be recognized and well documented.

> How much tests should we write to be confident we covered all cases? I share Lakshmi’s concern it is fragile and maintaining it reliably is difficult. 

Again, proper documentation and recognition of limitations.

> My preference is “option 3”, “make it work as is now”. But if it’s too hard I am ok to compromise. 

https://review.openstack.org/#/c/142452/ <https://review.openstack.org/#/c/142452/>. Took fairly reasonable amount of time for Nikolay to fix it. 

> Option 1 introduce a new syntax; although familiar to CLI users, I think it’s a bit out of place in YAML definition. 

Yes, agree.

> Option 4 is no go :)

Out of discussion.

Renat Akhmerov
@ Mirantis Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141218/10246b45/attachment.html>

More information about the OpenStack-dev mailing list