Revision history [back]

Excellent question!

SHORT ANSWER

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).

READ ON FOR DETAILS

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.

Thanks!