[openstack-dev] [Mistral] Notes on action YAML declaration and naming
Nikolay Makhotkin
nmakhotkin at mirantis.com
Fri Feb 14 13:26:07 UTC 2014
Current DSL snippet:
actions:
my-action
parameters:
foo: bar
response: # just agreed to change to 'results'
select: '$.server_id'
store_as: v1
'result' sounds better than 'response' and, I think, more fit to action
description.
And I suggest for a new word - 'output'; actually, this block describe how
the output will be taken and stored.
However, I agree that this block should be at action-property level:
actions:
my-action
result:
select: '$.server_id'
store_as: vm_id
parameters:
foo: bar
On Fri, Feb 14, 2014 at 12:36 PM, Renat Akhmerov <rakhmerov at mirantis.com>wrote:
>> On 14 Feb 2014, at 15:02, Dmitri Zimine <dz at stackstorm.com> wrote:
>> Current DSL snippet:
> actions:
> my-action
> parameters:
> foo: bar
> response: # just agreed to change to 'results'
>>> Just a note: "response" indentation here is not correct, it's not a
> parameter called "response" but rather a property of "my-action".
>> select: '$.server_id'
> store_as: v1
>> In the code, we refer to action.result_helper
>> 1) Note that *response* is not exactly a parameter. It doesn't doesn't
> refer to data. It's (query, variable) pairs, that are used to parse the
> results and post data to global context [1]. The terms response, or result,
> do not reflect what is actually happening here. Suggestions? Save? Publish?
> Result Handler?
>>> For explicitness we can use something like "result-handler" and initially
> I thought about this option. But I personally love conciseness and I think
> name "result" would be ok for this section meaning it defines the structure
> of the action result. "handler" is not 100% precise too because we don't
> actually handle a result here, we define the rules how to get this result.
>> I would appreciate to see other suggestions though.
>> 2) Whichever name we use for this output transformer, shall it be under
> parameters?
>>> No, what we have in this section is like a return value type for a regular
> method. Parameters define action input.
>> 3) how do we call action/task parameters? Think 'model' (which reflects in
> yaml, code, docs, talk, etc.)
> input and output? (+1)
> in and out? (-1)
> request and response? (-1) good for WebServices but not generic enough
> parameters and results? (ok)
>>> Could you please clarify your questions here? Not sure I'm following...
>> 4) Syntax simplification: can we drop 'parameters' keyword? Anything under
> action is action parameters, unless it's a reserved keyword, which the
> implementation can parse out.
>> actions:
> my-action
> foo: bar
> task-parameters: # not a keyword, specific to REST_API
> flavor_id:
> image_id:
> publish: # keyword
> select: '$.server_id'
> store_as: v1
>>> It will create problems like name ambiguity in case we need to have a
> parameter with the same names as keywords ("task-parameters" and "publish"
> in your example). My preference would be to leave it explicit.
>> Renat
>>> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
--
Best Regards,
Nikolay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140214/64500819/attachment.html>
More information about the OpenStack-dev
mailing list