Dmitri, Right now https://etherpad.openstack.org/p/mistral-poc is the only place where we described it. It shouldn’t be considered a specification, it was rather a playground where we tried to shape up our ideas. We’ll fix it using our latest ideas and changes captured in the code and create another etherpad for further long-term discussions.
Renat Akhmerov @ Mirantis Inc. On 15 Feb 2014, at 06:26, Dmitri Zimine <d...@stackstorm.com> wrote: > 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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev