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 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 * 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.  https://review.openstack.org/#/c/112938/  https://review.openstack.org/#/c/95937/  http://git.openstack.org/cgit/openstack/heat-templates/tree/hot/software-config/elements/heat-config _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev