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