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