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.
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? 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.
As for output: I would keep it as is. It defines the transformation of the
results of base action: a) defining new output variables and b) providing their
values, by transforming the output of base task. Very symmetric to 'input'.
Currently we stores into the global context, but it doesn't have to be so; I
think we eventually (soon) need to have task-specific section in the context
(more on this later)
Thoughts?
DZ.
PS. For the record, I am split on declarative action definitions. I like it,
but only as long as it stays simple. Very soon it becomes easier to express it
in code then in YAML.
On Feb 25, 2014, at 11:34 PM, Renat Akhmerov <rakhme...@mirantis.com> wrote:
> Hi team,
>
> I’m currently working on the first version of Data Flow and I would like to
> make sure we all clearly understand how to interpret “parameters" for tasks
> and actions when we declare them in Mistral DSL. I feel like I’m getting lost
> here a little bit. The problem is that we still don’t have a solid DSL spec
> since we keep changing our vision (especially after new members joined the
> team). But that may be fine, it’s life.
>
> I also have a couple of suggestions that I’d like to discuss with you. Sorry
> if that seems verbose, I’ll try to be as concise as possible.
>
> I took a couple of snippets from [1] and put them in here.
>
> # Snippet 1.
> Services:
> Nova:
> type: REST_API
> parameters:
> baseUrl: $.novaURL
> actions:
> createVM:
> parameters:
> url: /servers/{$.vm_id}
> method: POST
> output:
> select: $.server.id
> store-as: vm_id
>
> # Snippet 2.
> Workflow:
> tasks:
> createVM:
> action: Nova:createVM
> on-success: waitForIP
> on-error: sendCreateVMError
>
> “$.” - handle to workflow execution storage (what we call ‘context’ now)
> where we keep workflow variables.
>
> Let’s say our workflow input is JSON like this:
> {
> “novaURL”: “http://localhost:123”,
> “image_id”: “123"
> }
>
> Questions
>
> So the things that I don’t like or am not sure about:
>
> 1. Task “createVM” needs to use “image_id” but it doesn’t have any
> information about it its declaration.
> According to the current vision it should be like
> createVM:
> action: Nova:createVM
> parameters:
> image_id: $.image_id
> And at runtime “image_id" should be resolved to “123” get passed to action
> and, in fact, be kind of the third parameter along with “url” and “method”.
> This is specifically interesting because on one hand we have different types
> of parameters: “url” and “method” for REST_API action define the nature of
> the action itself. But “image_id” on the other hand is a dynamic data coming
> eventually from user input.
> So the question is: do we need to differentiate between these types of
> parameters explicitly and make a part of the specification?
> We also had a notion of “task-parameters” for action declarations which is
> supposed to be used to declare this second type of parameters (dynamic) but
> do we really need it? I guess if we clearly declare input and output at task
> level then actions should be able to use them according to their nature.
> 2. Action declaration “createVM” has section “response” which may not be ok
> in terms of level of abstraction.
> My current vision is that actions should not declare how we store the result
> (“output”) in execution. Ideally looking at tasks only should give us
> comprehensive understanding of how workflow data flows. So I would move
> “store-as” to task level.
>
> Suggestions
>
> 1. Define “input” and “output” at task level like this:
>
> createVM:
> input:
> image_id: $.image_id
> output: vm_id
>
> Where “output: vm_id” is basically a replacement for “store-as: vm_id” at
> action level, i.e. it’s a hint to Mistral to store the output of this task
> under “vm_id” key in execution context. Again, the idea is to define task and
> action responsibilities more strictly:
> Task is a high-level workflow building block which defines workflow logical
> step and how it modifies workflow data. Task doesn’t contain technical
> details on how it’s implemented.
> Action is an implementor of the workflow logical step defined by a task.
> Action defines specific algorithm of how task is implemented.
>
> 2. User “parameters” only for actions to specify their additional properties
> influencing their nature (like method for HTTP actions).
>
>
> Please let me know your thoughts. We can make required adjustments right now.
>
>
> [1] https://etherpad.openstack.org/p/mistral-poc
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
>
> _______________________________________________
> 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
