Open Stack

On 02/08/14 04:07, Allison Randal wrote:
> A few of us have been independently experimenting with Ansible as a
> backend for TripleO, and have just decided to try experimenting
> together. I've chatted with Robert, and he says that TripleO was always
> intended to have pluggable backends (CM layer), and just never had
> anyone interested in working on them. (I see it now, even in the early
> docs and talks, I guess I just couldn't see the forest for the trees.)
> So, the work is in line with the overall goals of the TripleO project.
>
> We're starting with a tiny scope, focused only on updating a running
> TripleO deployment, so our first work is in:
>
> - Create an Ansible Dynamic Inventory plugin to extract metadata from Heat
> - Improve/extend the Ansible nova_compute Cloud Module (or create a new
> one), for Nova rebuild
> - Develop a minimal handoff from Heat to Ansible, particularly focused
> on the interactions between os-collect-config and Ansible
>
> We're merging our work in this repo, until we figure out where it should
> live:
>
> https://github.com/allisonrandal/tripleo-ansible
>
> We've set ourselves one week as the first sanity-check to see whether
> this idea is going anywhere, and we may scrap it all at that point. But,
> it seems best to be totally transparent about the idea from the start,
> so no-one is surprised later.
>
Having pluggable backends for configuration seems like a good idea, and
Ansible is a great choice for the first alternative backend.

However what this repo seems to be doing at the moment is bypassing heat
to do a stack update, and I can only assume there is an eventual goal to
not use heat at all for stack orchestration too.

Granted, until blueprint update-failure-recovery lands[1] then doing a
stack-update is about as much fun as russian roulette. But this effort
is tactical rather than strategic, especially given TripleO's mission
statement.

If I were to use Ansible for TripleO configuration I would start with
something like the following:
* Install an ansible software-config hook onto the image to be triggered
by os-refresh-config[2][3]
* Incrementally replace StructuredConfig resources in
tripleo-heat-templates with SoftwareConfig resources that include the
ansible playbooks via get_file
* The above can start in a fork of tripleo-heat-templates, but can
eventually be structured using resource providers so that the deployer
chooses what configuration backend to use by selecting the environment
file that contains the appropriate config resources

Now you have a cloud orchestrated by heat and configured by Ansible. If
it is still deemed necessary to do an out-of-band update to the stack
then you're in a much better position to do an ansible push, since you
can use the same playbook files that heat used to bring up the stack.

[1] https://review.openstack.org/#/c/112938/
[2] https://review.openstack.org/#/c/95937/
[3]
http://git.openstack.org/cgit/openstack/heat-templates/tree/hot/software-config/elements/heat-config