[openstack-dev] [Mistral]
Dmitri Zimine
dz at stackstorm.com
Tue Feb 11 15:40:37 UTC 2014
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
More information about the OpenStack-dev
mailing list