On Fri, Dec 16, 2016 at 2:57 PM, Steven Hardy <sha...@redhat.com> wrote: > On Fri, Dec 16, 2016 at 02:03:10PM +0100, Thomas Herve wrote: >> On Fri, Dec 16, 2016 at 1:17 PM, Giulio Fidente <gfide...@redhat.com> wrote: >> > 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
Right, I mentioned that elsewhere. But it doesn't change the resource interface, for better or worse. > 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. It's unclear what changed since the discussion happened, just that you have a use case without another approach possible? >> > 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. Among the various solutions, I think that's the one I like the best for now. It doesn't touch the workflow resource interface, and it seems to fit relatively naturally (an API to call, a state to check, etc). >> > 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). Noted. -- Thomas __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev