Open Stack

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 <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
> 

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-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
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>