On Fri, Dec 16, 2016 at 02:03:10PM +0100, Thomas Herve wrote: > On Fri, Dec 16, 2016 at 1:17 PM, Giulio Fidente <[email protected]> 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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
