Re: [openstack-dev] [TripleO] workflow

[Dan Prince]

On Mon, 2015-12-07 at 16:00 +, Dougal Matthews wrote:
> 
> 
> On 7 December 2015 at 14:59, Dan Prince  wrote:
> > 
> > 
> > 
> > On Thu, 2015-12-03 at 15:47 -0500, Dan Prince wrote:
> > > On Tue, 2015-11-24 at 15:25 +, Dougal Matthews wrote:
> > > > On 23 November 2015 at 14:37, Dan Prince 
> > > > 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 
> > > > >  tripleo.update 
> > > > >  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
> > 
> > I made a short (13 minute) video demonstration that outlines what
> > using
> > Mistral might look like in TripleO. The demo uses the above
> > workflow as
> > an example.
> > 
> > https://youtu.be/bnAT37O-sdw
> > 
> That's really useful, Thanks! I can see this works really well in
> this example.
> 
> I don't think it is correct to talk about it in direct competition
> with the API. So far the code being written for the API is for
> template storage, validation and deployment. I think out of this only
> the deployment code could work well as a Minstral workflow. However,
> at the moment it is simply calling the validation in the API and then
> starting the deploy. It might be that a Minstral workflow could call
> the TripleO API for validation and then deploy to Heat. This would
> require some investigation.
> 
> Having said that, I completely agree that it seems like a compelling
> option as a replacement for the other code in the CLI. For the very
> workflow-y bits like registration and introspection, the CLI has
> never been great.
> 
> I have one question at the moment, if the workflows are stored in the
> Minstral database do you anticipate they are added during the
> undercloud install?

Sure. Perhaps we could namespace our workflows with "tripleo." and
install them as part of the undercloud install. That works if we expect
to use them out of the gate.

Dan

>  Since obviously we will want to version them etc. to match
> everything else in TripleO.
> 
>  
> >  
> > Dan
> > 
> > >
> > > >
> > > > >  Dan
> > > > >
> > > > >
> > _
> > > > > __
> > > > > ___
> > > > > OpenStack Development Mailing List (not for usage questions)
> > > > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subjec
> > t:un
> > > > > su
> > > > > bscribe
> > > > > 

Re: [openstack-dev] [TripleO] workflow

[Dan Prince]

On Thu, 2015-12-03 at 15:47 -0500, Dan Prince wrote:
> On Tue, 2015-11-24 at 15:25 +, Dougal Matthews wrote:
> > On 23 November 2015 at 14:37, Dan Prince 
> > 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 
> > >  tripleo.update 
> > >  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

I made a short (13 minute) video demonstration that outlines what using
Mistral might look like in TripleO. The demo uses the above workflow as
an example.

https://youtu.be/bnAT37O-sdw


Dan

> 
> > 
> > >  Dan
> > > 
> > > _
> > > __
> > > ___
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:un
> > > su
> > > 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:unsu
> > bs
> > 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: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

Re: [openstack-dev] [TripleO] workflow

[Dougal Matthews]

On 7 December 2015 at 14:59, Dan Prince  wrote:

>
>
>
> On Thu, 2015-12-03 at 15:47 -0500, Dan Prince wrote:
> > On Tue, 2015-11-24 at 15:25 +, Dougal Matthews wrote:
> > > On 23 November 2015 at 14:37, Dan Prince 
> > > 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 
> > > >  tripleo.update 
> > > >  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
>
> I made a short (13 minute) video demonstration that outlines what using
> Mistral might look like in TripleO. The demo uses the above workflow as
> an example.
>
> https://youtu.be/bnAT37O-sdw
>
>
That's really useful, Thanks! I can see this works really well in this
example.

I don't think it is correct to talk about it in direct competition with the
API. So far the code being written for the API is for template storage,
validation and deployment. I think out of this only the deployment code
could work well as a Minstral workflow. However, at the moment it is simply
calling the validation in the API and then starting the deploy. It might be
that a Minstral workflow could call the TripleO API for validation and then
deploy to Heat. This would require some investigation.

Having said that, I completely agree that it seems like a compelling option
as a replacement for the other code in the CLI. For the very workflow-y
bits like registration and introspection, the CLI has never been great.

I have one question at the moment, if the workflows are stored in the
Minstral database do you anticipate they are added during the undercloud
install? Since obviously we will want to version them etc. to match
everything else in TripleO.



>
> Dan
>
> >
> > >
> > > >  Dan
> > > >
> > > > _
> > > > __
> > > > ___
> > > > OpenStack Development Mailing List (not for usage questions)
> > > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:un
> > > > su
> > > > 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:unsu
> > > bs
> > > cribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > _
> > _
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 

Re: [openstack-dev] [TripleO] workflow

[Dmitry Tantsur]

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 +, Dougal Matthews wrote:

On 23 November 2015 at 14:37, Dan Prince  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 
  tripleo.update 
  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-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




__
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

Re: [openstack-dev] [TripleO] workflow

[John Trowbridge]

On 12/03/2015 03:47 PM, Dan Prince wrote:
> On Tue, 2015-11-24 at 15:25 +, Dougal Matthews wrote:
>> On 23 November 2015 at 14:37, Dan Prince  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 
>>>  tripleo.update 
>>>  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

Re: [openstack-dev] [TripleO] workflow

[Dan Prince]

On Tue, 2015-11-24 at 15:25 +, Dougal Matthews wrote:
> On 23 November 2015 at 14:37, Dan Prince  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 
> >  tripleo.update 
> >  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

Re: [openstack-dev] [TripleO] workflow

[Dougal Matthews]

On 23 November 2015 at 14:37, Dan Prince  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 
>  tripleo.update 
>  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.

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

Re: [openstack-dev] [TripleO] workflow

[Steve Baker]

On 24/11/15 03:37, Dan Prince 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 
  tripleo.update 
  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?
This would be useful, but we don't need to wait for zaqar integration 
before we can try this. We should be able to do this once the deployment 
transport is switched to swift TempURLs. I'll be working on this soon 
and will try adding support for ad-hoc deployment snippets via 
python-tripleoclient (and later maybe ansible or mistral).

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.



Definitely a worthy experiment, lets see how it works out.


__
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