Open Stack

Dmitri, in our concerns under word 'input' we assume a block contains the
info about how the input data will be taken for corresponding task from
initial context. So, it will be a kind of expression (e.g. YAQL).

Renat, am I right?


On Fri, Feb 14, 2014 at 9:51 PM, Dmitri Zimine <dz at stackstorm.com> wrote:

> 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 <rakhmerov at mirantis.com>
> wrote:
>
> "output" looks nice!
>
>
> Renat Akhmerov
> @ Mirantis Inc.
>
> On 14 Feb 2014, at 20:26, Nikolay Makhotkin <nmakhotkin at mirantis.com>
> 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 <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
>  _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> 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/20140215/4f644d32/attachment.html>