Open Stack

Excerpts from Steve Baker's message of 2014-08-10 15:33:26 -0700:
> 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.
> 

TripleO is intended to be loosely coupled for many components, not just
in-instance configuration.

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

We intend to stay modular. Ansible won't replace Heat from end to end.

Right now we're stuck with an update that just doesn't work. It isn't
just about update-failure-recovery, which is coming along nicely, but
it is also about the lack of signals to control rebuild, poor support
for addressing machines as groups, and unacceptable performance in
large stacks.

We remain committed to driving these things into Heat, which will allow
us to address these things the way a large scale operation will need to.

But until we can land those things in Heat, we need something more
flexible like Ansible to go around Heat and do things in the exact
order we need them done. Ansible doesn't have a REST API, which is a
non-starter for modern automation, but the need to control workflow is
greater than the need to have a REST API at this point.

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

That would be a good plan if we wanted to fix issues with os-*-config,
but that is the opposite of reality. We are working around Heat
orchestration issues with Ansible.