On 24/11/15 03:37, Dan Prince wrote:
There are lots of references to "workflow" within TripleO conversations
these days. We are at (or near) the limit of what we can do within Heat
with regards to upgrades. We've got a new TripleO API in the works (a
new version of Tuskar basically) that is specifically meant to
encapsulates business logic workflow around deployment. And, Lots of
interest in using Ansible for this and that.
So... Last week I spent a bit of time tinkering with the Mistral
workflow service that already exists in OpenStack and after a few
patches got it integrated into my undercloud:
https://etherpad.openstack.org/p/tripleo-undercloud-workflow
One could imagine us coming up with a set of useful TripleO workflows
(something like this):
tripleo.deploy <deploy workflow parameters...>
tripleo.update <upgrade workflow parameters....>
tripleo.run_ad_hoc_whatever_on_specific_roles <....>
Since Mistral (the OpenStack workflow service) can already interact w/
keystone and has a good many hooks to interact with core OpenStack
services like Swift, Heat, and Nova we might get some traction very
quickly here. Perhaps we add some new Mistral Ironic actions? Or
imagine smaller more focused Heat configuration stacks that we drive
via Mistral? Or perhaps we tie in Zaqar (which already has some
integration into os-collect-config) to run ad-hoc deployment snippets
on specific roles in an organized fashion?
This would be useful, but we don't need to wait for zaqar integration
before we can try this. We should be able to do this once the deployment
transport is switched to swift TempURLs. I'll be working on this soon
and will try adding support for ad-hoc deployment snippets via
python-tripleoclient (and later maybe ansible or mistral).
Or wrapping mistral w/
tripleoclient to allow users to more easily call TripleO specific
workflows (enhancing the user feedback like we do with our heatclient
wrapping already)?
Where all this might lead... I'm not sure. But I feel like we might
benefit by adding a few extra options to our OpenStack deployment tool
chain.
Definitely a worthy experiment, lets see how it works out.
__________________________________________________________________________
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
