Ask Your Question

how does Mistral manage vars in the flow? what are the capabilities?

asked 2014-03-19 04:52:56 -0500

Bilal Saleh gravatar image

let's assume I want to create 3 VMs simultaneously, using a pre-defined Mistral flow. my question is: how does Mistral manage the output of the created VMs (for instance: vm_ip variable, will it be overridden by the last VM created)? Is it possible to defined dynamic vars in the flow (DSL specification)?

edit retag flag offensive close merge delete

2 answers

Sort by ยป oldest newest most voted

answered 2014-03-19 07:49:20 -0500

Renat gravatar image

Excellent question!


Yes. It's possible now with composing a workflow in a certain way. For example, we can have 3 tasks with different parameters (image_ref, VM_number), action declaration may be the same for all 3 tasks and it always returns a vm id (extracted from raw HTTP response). The key point here is that tasks publish vm ids coming from actions under different names. The downside here is that we have to define 3 tasks.

Currently, there's not a facility in Mistral that would allow doing it in a simpler way. Currently we're working on a capability that will allow it. It'll be possible to repeat one task a configured number of times (e.g. 3 times to create 3 VMs).


Overall schema of how vars are managed is pretty simple. There is a notion of workflow execution context that holds variables. It's basically just a dictionary (or we can think of it as something representable in JSON). So a task gets an inbound context, does its useful job, then optionally publishes vars (or replaces existing ones) to the context and passes it on to the next task as an inbound context that works the same way. In fact, speaking about details, every time system makes a copy of the context and transfers it along with task information itself over async transport (currently AMQP). It allows not to use a single concurrently accessed object in DB, provides isolation for workflow branches etc.

If we take a single VM creation then it works as follows:

  • Task defines parameters for corresponding http action (to make a request to Nova): image_ref, nova_url.
  • HTTP action has a rule how to convert task parameters into HTTP request (composing url, method etc. taking task parameters into account).
  • HTTP action has a rule how to convert a raw HTTP response into a useful data structure (e.g. parse vm id from json body).
  • HTTP action runs, converts its result to a form declared in the action.
  • Task defines how to publish that action result into execution context (declaring a var name, e.g. vm_ip)
  • Subsequent tasks now see this new variable in the context and can use it as a parameter value or override it if necessary. Even if overridden, the original value is always accessible by the full name containing a task name.

Once we implement 'repeat' capability we'll be able to build loops to repeat this process.


edit flag offensive delete link more

answered 2014-03-19 08:16:18 -0500

Bilal Saleh gravatar image

Thank you !!

edit flag offensive delete link more

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower


Asked: 2014-03-19 04:52:56 -0500

Seen: 200 times

Last updated: Mar 19 '14