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 <[email protected]> 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 <[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 > > -- Best Regards, Nikolay
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
