[openstack-dev] [Mistral] Understanding parameters for tasks and actions

Renat Akhmerov rakhmerov at mirantis.com
Wed Feb 26 07:34:23 UTC 2014


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.



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


More information about the OpenStack-dev mailing list