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? 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. Dan __________________________________________________________________________ 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