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
