Open Stack

On 26 Feb 2014, at 16:30, Dmitri Zimine <dz at stackstorm.com> wrote:

> My understanding, correct me if I'm missing the intention: 
> 
> Action are defined as code, aka REST_API or SEND_EMAIL. 
> These are base actions, they are analogous to function definitions. 
> 
> Tasks is a set of parameters for the action.
> 
> Actions can be also defined declaratively, under Services, based on base actions. 
> These are "service", or "declared" actions, they are analogous to partials. 
> In the simplest form, they 1) set some of the parameters on the base functions and 2) define outputs.

Ok,

Just want to make sure we understand the terminology in the same way:
Base action -  what we call “Action type”. For me it’s really like a class from OOP. Specific declaration - instance.
Declared (or service) actions - action declarations under “Services”. We’ve been calling them just “actions”. Btw, I believe we can revisit the necessity to group them under services, in some cases it doesn’t make sense.
Service - nothing else but a means to group several actions having the same type so that we could avoid duplications of parameters (e.g. base url for Nova) and better communicate the idea that they are just parts of the same artefacts (e.g. group of requests to Nova where Nova is a service)

Is everything correct?

> But I guess what Renat is trying to capture here, is to also define new input parameters, (analogous to  changing a function signature). If so, they become adapters; and there need to be a) define new parameters and b) transform the new parameters (input) into original parameters of the base action. 
> 
> Is this how we think about it?

Kind of, but not exactly. Here are my points:
These new input parameters can be even dynamic in many cases. E.g. when we send an HTTP request we should be able to
use the same action in many tasks with different parameters (different signature)
attach parameters (in query string or POST body) whose names and values are known only at runtime
Do we need to distinguish between static and dynamic parameters? We thought yes, but the more I think about it the more this separation seems artificial to me. Hence, the idea is to abandon “parameters” completely and call it “input”
And the most important thing is logical separation between task and actions. In my opinion, defining “store-as” in action level is incorrect (even though I suggested it initially). Let’s say we have a simple workflow: task1 -> task2 -> task3. At this level we don’t know anything about actions, they are just implementation logic of the tasks. So as a user I also want to see how task1, task2 and task3 transform data that moves from start to end of the workflow. In this case I would have information like this: data_context[first_name=“John", last_name=“Doe"] -> task1[input=“first_name, last_name”, output=“full_name”] -> task2[input=“full_name", output=“greeting_message”] -> task3[input=“greeting_message”]. This is a made up example but I hope it communicates my point well enough. Looking at this last chain of tasks I see how data evolves: task1 consumes “first_name” and “last_name” from workflow data context and puts “full_name” in there, task2 consumes “full_name” and puts “greeting_message” variable in data context, task3 consumes “greeting_message” and doesn’t put anything into data context. So the main idea is that input and output are properties of task, first of all. For that reason it’s incorrect to define at action level how we store the result in data context (“store-as”), it’s just not the right layer of abstraction to do that. Action should only be able to implement what’s declared at task level. In this regard what you wrote about “adapters” makes sense, it becomes a tricky part when we transform input from task level to action level. Just a raw idea is that it could be done in a conventional way (e.g. it’s simply adding all the input parameters into query string or request body) but it may not be enough. 

Don’t get me wrong: I’m not pushing anything. I’m in search myself so I’m appealing to you to brainstorm this and get to the same page asap.

> If yes, the syntax to express it might be something like this
> 
> # Snippet 1.
> Services:
>   Nova:
>     type: REST_API
>       parameters:
>         baseUrl: $.novaURL
>         actions:
>           createVM:
>             parameters: # partial set for the parameters of base action.
>                method: POST
>                url: /servers/{{service-id}} # sets up the initial parameter, using the new input 
>             input: 
>                service-id: # defines a new input
>             output: 
>                select: $.server.id
>                store-as: vm_id
> # Snippet 2.
> Workflow:
>   tasks:
>     createVM:
>       action: Nova:createVM
>         parameters:
>           service-id: {{$.vm_id}}
>         on-success: waitForIP
>         on-error: sendCreateVMError
> 
> Better ideas on referencing input, better than {{service-id}}are welcome. 
> 
> The point here is we don't refer the context variables in Service definitions. Only transformation of input, with some static text. The "service" actions now look symmetric on input/output.

Yes, makes sense. As you said “we don’t refer the context variables” and that’s why I’m against of having “store-as” in action declaration, it indirectly refers to the context (the output of action will be stored under this name in the context).


Renat Akhmerov
@ Mirantis Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140227/bc2c1383/attachment.html>