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 <d...@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 <rakhme...@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 <d...@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@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
