Open Stack

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.