[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