Open Stack

On 12/06/2015 05:33 PM, John Trowbridge wrote:
>
>
> 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.

Yeah, looks really good, except for 
https://github.com/dprince/tripleo-mistral-workflows/blob/master/tripleo/baremetal.yaml#L35-L39 
still talks about introspecting nodes in AVAILABLE state, which must be 
killed with fire. We should use ENROLL state when importing nodes 
instead and require a user to explicitly move nodes out of AVAILABLE 
state, if they want them to be introspected.

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