[openstack-dev] [Mistral]
Dmitri Zimine
dz at stackstorm.com
Wed Feb 26 00:32:17 UTC 2014
I have created a blueprint to capture the intention to simplify calling standard actions:
https://blueprints.launchpad.net/mistral/+spec/mistral-shorthand-action-in-dsl
DZ>
On Feb 11, 2014, at 7:40 AM, Dmitri Zimine <dz at stackstorm.com> wrote:
> Yes it makes sense, let's draft how it may look;
>
> and also think over implementation implications - now we separate task parameters, action parameters, and service parameters, we may need to merge them when instantiating the action.
>
> DZ.
>
> On Feb 11, 2014, at 6:19 AM, Renat Akhmerov <rakhmerov at mirantis.com> wrote:
>
>> Dmitry, I think you are right here. I think for simple case we should be able to use in-place action definition without having to define the action separately. Like you said it’s only valuable if we need to reuse it.
>>
>> The only difference I see between std:send-email and something like REST_API is that a set of parameters for the latter is dynamic (versus std:send-email where it’s always “recipients”, “subject”, “body”). Even though it’s still the same protocol (HTTP) but a particular request representation may be different (i.e. query string, headers, the structure of body in case POST etc.). But I think that doesn’t cancel the idea of being able to define the action along with the task itself.
>>
>> So good point. As for the syntax itself, we need to think it over. In the snippet you provided “action: std:REST_API”, so we need to make sure not to have ambiguities in the ways how we can refer actions. A convention could be “if we don’t use a namespace we assume that there’s a separate action definition included into the same workbook, otherwise it should be considered in-place action definition and task property “action” refers to an action type rather than the action itself”. Does that make sense?
>
>>
>> Renat Akhmerov
>> @ Mirantis Inc.
>>
>> On 11 Feb 2014, at 16:23, Dmitri Zimine <dz at stackstorm.com> wrote:
>>
>>> Do we have (or think about) a shorthand to calling REST_API action, without defining a service?
>>>
>>> FULL DSL:
>>>
>>> Services:
>>> TimeService:
>>> type: REST_API
>>> parameters:
>>> baseUrl:http://api.timezonedb.com
>>> key:<my_api_key>
>>> actions:
>>> get-time:
>>> task-parameters:
>>> zone:
>>> Workflow:
>>> tasks:
>>> timeInToronto:
>>> action: TimeService:get-time
>>> parameters:
>>> zone: "America/Toronto"
>>>
>>> SHORTCUT - may look something like this:
>>>
>>> Workflow:
>>> tasks:
>>> timeInToronto:
>>> action:std:REST_API
>>> parameters:
>>> baseUrl: "http://api.timezonedb.com"
>>> method: "GET"
>>> parameters: "zone=/America/Toronto&key=<my_api_key>"
>>>
>>> Why asking:
>>>
>>> 1) analogy with std:send-email action. I wonder do we have to make user define Service for std:send-email? and I think that for standard tasks we shouldn't have to. If there is any thinking on REST_API, it may apply here.
>>>
>>> 2) For a one-off web service calls the complete syntax is may be overkill (but yes, it comes handy for reuse). See examples below.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20140225/9850b1ea/attachment.html>
More information about the OpenStack-dev
mailing list