<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 7 December 2015 at 14:59, Dan Prince <span dir="ltr"><<a href="mailto:dprince@redhat.com" target="_blank">dprince@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Thu, 2015-12-03 at 15:47 -0500, Dan Prince wrote:<br>
> On Tue, 2015-11-24 at 15:25 +0000, Dougal Matthews wrote:<br>
> > On 23 November 2015 at 14:37, Dan Prince <<a href="mailto:dprince@redhat.com">dprince@redhat.com</a>><br>
> > wrote:<br>
> > > There are lots of references to "workflow" within TripleO<br>
> > > conversations<br>
> > > these days. We are at (or near) the limit of what we can do<br>
> > > within<br>
> > > Heat<br>
> > > with regards to upgrades. We've got a new TripleO API in the<br>
> > > works<br>
> > > (a<br>
> > > new version of Tuskar basically) that is specifically meant to<br>
> > > encapsulates business logic workflow around deployment. And, Lots<br>
> > > of<br>
> > > interest in using Ansible for this and that.<br>
> > ><br>
> > > So... Last week I spent a bit of time tinkering with the Mistral<br>
> > > workflow service that already exists in OpenStack and after a few<br>
> > > patches got it integrated into my undercloud:<br>
> > ><br>
> > > <a href="https://etherpad.openstack.org/p/tripleo-undercloud-workflow" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/tripleo-undercloud-workflow</a><br>
> > ><br>
> > > One could imagine us coming up with a set of useful TripleO<br>
> > > workflows<br>
> > > (something like this):<br>
> > ><br>
> > >  tripleo.deploy <deploy workflow parameters...><br>
> > >  tripleo.update <upgrade workflow parameters....><br>
> > >  tripleo.run_ad_hoc_whatever_on_specific_roles <....><br>
> > ><br>
> > > Since Mistral (the OpenStack workflow service) can already<br>
> > > interact<br>
> > > w/<br>
> > > keystone and has a good many hooks to interact with core<br>
> > > OpenStack<br>
> > > services like Swift, Heat, and Nova we might get some traction<br>
> > > very<br>
> > > quickly here. Perhaps we add some new Mistral Ironic actions? Or<br>
> > > imagine smaller more focused Heat configuration stacks that we<br>
> > > drive<br>
> > > via Mistral? Or perhaps we tie in Zaqar (which already has some<br>
> > > integration into os-collect-config) to run ad-hoc deployment<br>
> > > snippets<br>
> > > on specific roles in an organized fashion?  Or wrapping mistral<br>
> > > w/<br>
> > > tripleoclient to allow users to more easily call TripleO specific<br>
> > > workflows (enhancing the user feedback like we do with our<br>
> > > heatclient<br>
> > > wrapping already)?<br>
> > ><br>
> > > Where all this might lead... I'm not sure. But I feel like we<br>
> > > might<br>
> > > benefit by adding a few extra options to our OpenStack deployment<br>
> > > tool<br>
> > > chain.<br>
> > I think this sounds promising. Lots of the code in the CLI is about<br>
> > managing workflows. For example when doing introspection we change<br>
> > the node state, poll for the result, start introspection, poll for<br>
> > the result, change the node state back and poll for the result. If<br>
> > mistral can help here I expect it could give us a much more robust<br>
> > solution.<br>
><br>
> Hows this look:<br>
><br>
> <a href="https://github.com/dprince/tripleo-mistral-" rel="noreferrer" target="_blank">https://github.com/dprince/tripleo-mistral-</a><br>
> workflows/blob/master/tripleo/baremetal.yaml<br>
<br>
</div></div>I made a short (13 minute) video demonstration that outlines what using<br>
Mistral might look like in TripleO. The demo uses the above workflow as<br>
an example.<br>
<br>
<a href="https://youtu.be/bnAT37O-sdw" rel="noreferrer" target="_blank">https://youtu.be/bnAT37O-sdw</a><br>
<br></blockquote><div><br></div><div>That's really useful, Thanks! I can see this works really well in this example.<br><br>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.<br><br></div><div>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.<br><br></div><div>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? Since obviously we will want to version them etc. to match everything else in TripleO.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Dan<br>
<br>
><br>
> ><br>
> > >  Dan<br>
> > ><br>
> > > _________________________________________________________________<br>
<div class="HOEnZb"><div class="h5">> > > __<br>
> > > _______<br>
> > > OpenStack Development Mailing List (not for usage questions)<br>
> > > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:un" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:un</a><br>
> > > su<br>
> > > bscribe<br>
> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> > ><br>
> > ___________________________________________________________________<br>
> > __<br>
> > _____<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsu" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsu</a><br>
> > bs<br>
> > cribe<br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _____________________________________________________________________<br>
> _____<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubs" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubs</a><br>
> cribe<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>