On 12/03/2015 03:47 PM, Dan Prince wrote: > 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 >
This is a really good starter example because the bulk inspection command is particularly problematic. I like this a lot. One really nice thing here is that we get a REST API for free by using Mistral. >> >>> 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 > __________________________________________________________________________ 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
