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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
