I like output, too. But it should go with 'input'
In summary, there are two alternatives.
Note that I moved task-parameters under parameters. Ok with this?
actions:
my-action
input:
foo: bar
task-parameters:
flavor_id:
image_id:
output:
select: '$.server_id'
store_as: v1
this maps to action(input, *output)
actions:
my-action
parameters:
foo: bar
task-parameters:
flavor_id:
image_id:
result:
select: '$.server_id'
store_as: v1
this maps to result=action(parameters)
On Feb 14, 2014, at 8:40 AM, Renat Akhmerov <[email protected]> wrote:
> “output” looks nice!
>
>
> Renat Akhmerov
> @ Mirantis Inc.
>
> On 14 Feb 2014, at 20:26, Nikolay Makhotkin <[email protected]> wrote:
>
>> 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 <[email protected]>
>> wrote:
>>
>> On 14 Feb 2014, at 15:02, Dmitri Zimine <[email protected]> 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
>> [email protected]
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> --
>> Best Regards,
>> Nikolay
>> _______________________________________________
>> OpenStack-dev mailing list
>> [email protected]
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> [email protected]
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
