Open Stack

On 12/16/2016 01:56 PM, Christian Schwede wrote:
>> 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.
>>
>> 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 think it needs to be triggered a bit later actually? For the Swift use
> case it needs to be executed after all instances are created (but
> preferably before starting any Puppet actions on the nodes), not when
> the CREATE/UPDATE itself actually starts.

yep, I was referring to the workflow resource CREATE/UPDATE action

we have complete control in Heat about when the workflow resource itself 
should be created

>> Alternatively, would an ex-novo Execution resource make more sense?
>>
>> Or are there different ideas, approaches to the problem?
>
> As a workaround for now I'm using the signal URL and trigger it in a
> shell script on the nodes (the shell script is running anyways to fetch
> and validate the rings). To avoid multiple parallel workflow executions
> triggered by a dozen nodes I set a flag in the Mistral environment;
> further actions will immediately return then.
>
> I'd prefer a different and cleaner approach like you proposed but for me
> that's working well for the moment.

ack
-- 
Giulio Fidente
GPG KEY: 08D733BA