Open Stack

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>