<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 23 November 2015 at 14:37, 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">There are lots of references to "workflow" within TripleO conversations<br>
these days. We are at (or near) the limit of what we can do within Heat<br>
with regards to upgrades. We've got a new TripleO API in the works (a<br>
new version of Tuskar basically) that is specifically meant to<br>
encapsulates business logic workflow around deployment. And, Lots 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 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 interact w/<br>
keystone and has a good many hooks to interact with core OpenStack<br>
services like Swift, Heat, and Nova we might get some traction very<br>
quickly here. Perhaps we add some new Mistral Ironic actions? Or<br>
imagine smaller more focused Heat configuration stacks that we 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 snippets<br>
on specific roles in an organized fashion?  Or wrapping mistral w/<br>
tripleoclient to allow users to more easily call TripleO specific<br>
workflows (enhancing the user feedback like we do with our heatclient<br>
wrapping already)?<br>
<br>
Where all this might lead... I'm not sure. But I feel like we might<br>
benefit by adding a few extra options to our OpenStack deployment tool<br>
chain.<br></blockquote><div><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dan<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>
</blockquote></div><br></div></div>