Open Stack

Ok, I see.  

Do we have a spec that describes this?
Lets spell it out and describe the whole picture of input, output, parameters, and result. 

DZ> 


On Feb 14, 2014, at 1:01 PM, Nikolay Makhotkin <nmakhotkin at mirantis.com> wrote:

> 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
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140214/1879099a/attachment.html>