Open Stack

On Tue, 2015-11-24 at 15:25 +0000, Dougal Matthews wrote:
> On 23 November 2015 at 14:37, Dan Prince <dprince at redhat.com> 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?  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.
> I think this sounds promising. Lots of the code in the CLI is about
> managing workflows. For example when doing introspection we change
> the node state, poll for the result, start introspection, poll for
> the result, change the node state back and poll for the result. If
> mistral can help here I expect it could give us a much more robust
> solution.

Hows this look:

https://github.com/dprince/tripleo-mistral-
workflows/blob/master/tripleo/baremetal.yaml

> 
> >  Dan
> > 
> > ___________________________________________________________________
> > _______
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsu
> > bscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> _____________________________________________________________________
> _____
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev