Open Stack

On Thu, 2015-12-03 at 15:47 -0500, Dan Prince wrote:
> 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

I made a short (13 minute) video demonstration that outlines what using
Mistral might look like in TripleO. The demo uses the above workflow as
an example.

https://youtu.be/bnAT37O-sdw


Dan

> 
> > 
> > >  Dan
> > > 
> > > _________________________________________________________________
> > > __
> > > _______
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:un
> > > su
> > > 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:unsu
> > bs
> > cribe
> > 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