[openstack-dev] [Heat][TripleO] How to run mistral workflows via templates

Thomas Herve therve at redhat.com
Fri Dec 16 13:03:10 UTC 2016


On Fri, Dec 16, 2016 at 1:17 PM, Giulio Fidente <gfidente at redhat.com> wrote:
> hi,
>
> we're trying to address in TripleO a couple of use cases for which we'd like
> to trigger a Mistral workflow from a Heat template.
>
> One example where this would be useful is the creation of the Swift rings,
> which need some data related to the Heat stack (like the list of Swift nodes
> and their disks), so it can't be executed in advance, yet it provides data
> which is needed to complete successfully the deployment of the overcloud.
>
> Currently we can create a workflow from Heat, but we can't trigger its
> execution and also we can't block Heat on the result of the execution.

You can trigger it out of band with resource signal. But you're right,
Heat won't wait for the result.

> I was wondering if it would make sense to have a property for the existing
> Workflow resource to let the user decide if the workflow should *also* be
> triggered on CREATE/UPDATE? And if it would make sense to block the Workflow
> resource until the execution result is returned in that case?

I'm not super in favor of that. It's conflicting 2 different concepts here.

> Alternatively, would an ex-novo Execution resource make more sense?

We had some discussions here: https://review.openstack.org/267770.
Executing things as part of a template is a tricky proposition. I
think we'd like it to be more akin to software deployments, where it
runs on actions. We also were talking about doing something like AWS
CustomResource in Heat, which may look like WorkflowExecution (at
least one part of it).

> Or are there different ideas, approaches to the problem?

If you could define the event outside of Heat (in your example,
publish something when a swift node is available), then you could use
Zaqar to trigger your workflow. If you want Heat to block that won't
do it though.


-- 
Thomas



More information about the OpenStack-dev mailing list