Open Stack

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?

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