On Tue, 2015-11-24 at 15:25 +0000, Dougal Matthews wrote: > On 23 November 2015 at 14:37, Dan Prince <dpri...@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-requ...@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-requ...@lists.openstack.org?subject:unsubs > cribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
