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