[openstack-dev] [Mistral] Notes on action YAML declaration and naming
Renat Akhmerov
rakhmerov at mirantis.com
Mon Feb 17 05:27:41 UTC 2014
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 <dz at 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 <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
>
> _______________________________________________
> 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/20140217/f322ffac/attachment.html>
More information about the OpenStack-dev
mailing list