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 <nmakhot...@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 <d...@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 <rakhme...@mirantis.com> wrote: > >> “output” looks nice! >> >> >> Renat Akhmerov >> @ Mirantis Inc. >> >> On 14 Feb 2014, at 20:26, Nikolay Makhotkin <nmakhot...@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 <rakhme...@mirantis.com> >>> wrote: >>> >>> On 14 Feb 2014, at 15:02, Dmitri Zimine <d...@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@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> >>> -- >>> Best Regards, >>> Nikolay >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Best Regards, > Nikolay > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
