On Fri, Dec 16, 2016 at 04:02:51PM +0100, Thomas Herve wrote:
On Fri, Dec 16, 2016 at 2:57 PM, Steven Hardy email@example.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 firstname.lastname@example.org 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:
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
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
handlesignal and add a boolean to each handlefoo 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?
Well, honestly yes - my perspective has changed somewhat as I've had recent
first-hand exposure to several problems which would be very nicely solved
by the additional Execution resource (or interface) under discussion.
Also, it's unclear if the hinted-at future model involving zaqar
notifications actually solves this (or at least not in it's current form),
so I'm looking at this from a pragmatic standpoint and trying to find a
relatively low-impact way to just solve the problem and move forward.
E.g in https://review.openstack.org/#/c/267770/ the execution resource was
rejected based partly on the expectation of a future Zaqar driven model
satisfying the same requirement, which was futher described in this summit
While the patterns discussed there are definitely compelling, they still
don't address the requirement of wanting to just run some mistral workflow
as part of the heat stack lifecycle?
AFAICT it's describing an independent (of Heat) system which can take
actions in an event/alarm driven manner e.g the interaction between
telemetry services, Zaqar and Mistral are configured by, but essentially
asynchronous to Heat - all great, but doesn't solve our problem?
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,
Yeah, honestly I think it's a simple step which some folks will find
useful, and it's likely to be low-imact from a heat perspective (folks can
continue to prefer the Aodh/Zaqar approach if it suits their use-case
As always, open to suggestions of a better way to approach this, but atm
I'm feeling like just going ahead with the WorkflowExecution resource
(ensuring it can handle all lifecycle actions, e.g just like
SoftwareDeployment/SoftwareCompoinent which is quite conceptually similar,
as noted in 267770 ...) is the most workable option.