Open Stack

On Fri, Dec 16, 2016 at 02:03:10PM +0100, Thomas Herve wrote:
> 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.

Well, they're already conflated in the mistral workflow resource, because
we allow creating an execution by sending a signal:

https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/mistral/workflow.py#L586

That satisfies the requirement for asynchronous (signal/alarm driven)
workflow execution, but we need the synchronous version that can be fully
integrated into the heat stack lifecycle (without external dependencies on
alarms etc).

I know we've previously tried to steer execute/run type actions to signal
driven interfaces (and I myself have opposed these kinds of resources in
the past, to be honest).  However, I can't currently see a better way to
handle this requirement, and given it may be pretty easy to fix (refactor
handle_signal and add a boolean to each handle_foo function), I think this
discussion warrants revisiting.

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

Yeah I think whichever approach we take, a list of actions similar to
SoftwareDeployment makes sense, then you can elect to run a specific
workflow at any state transition in the lifecycle.

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

Yeah that doesn't solve our use-case, we want to run a workflow during an
overcloud stack create, wait for the result, then continue (or fail).

Thanks!

Steve