Open Stack

On Mon, 2015-12-07 at 16:00 +0000, Dougal Matthews wrote:
> 
> 
> On 7 December 2015 at 14:59, Dan Prince <dprince at redhat.com> wrote:
> > 
> > 
> > 
> > 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
> > 
> That's really useful, Thanks! I can see this works really well in
> this example.
> 
> I don't think it is correct to talk about it in direct competition
> with the API. So far the code being written for the API is for
> template storage, validation and deployment. I think out of this only
> the deployment code could work well as a Minstral workflow. However,
> at the moment it is simply calling the validation in the API and then
> starting the deploy. It might be that a Minstral workflow could call
> the TripleO API for validation and then deploy to Heat. This would
> require some investigation.
> 
> Having said that, I completely agree that it seems like a compelling
> option as a replacement for the other code in the CLI. For the very
> workflow-y bits like registration and introspection, the CLI has
> never been great.
> 
> I have one question at the moment, if the workflows are stored in the
> Minstral database do you anticipate they are added during the
> undercloud install?

Sure. Perhaps we could namespace our workflows with "tripleo." and
install them as part of the undercloud install. That works if we expect
to use them out of the gate.

Dan

>  Since obviously we will want to version them etc. to match
> everything else in TripleO.
> 
>  
> >  
> > Dan
> > 
> > >
> > > >
> > > > >  Dan
> > > > >
> > > > >
> > _________________________________________________________________
> > > > > __
> > > > > _______
> > > > > OpenStack Development Mailing List (not for usage questions)
> > > > > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subjec
> > t: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-d
> > ev
> > >
> > >
> > ___________________________________________________________________
> > __
> > > _____
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:un
> > subs
> > > 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: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