Open Stack

On Fri, Dec 16, 2016 at 04:02:51PM +0100, Thomas Herve wrote:
> On Fri, Dec 16, 2016 at 2:57 PM, Steven Hardy <shardy at 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 <gfidente at 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?

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
talk:

https://www.openstack.org/videos/video/building-self-healing-applications-with-aodh-zaqar-and-mistral

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

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

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.

Thanks!

Steve