Open Stack

Hi all,

I've had various discussions about $subject, which have been re-started
lately due to some excellent work going on in the Heat community (Rabi
Mishra's work integrating SoftwareDeployments with various container
launching tools [1])

tl;dr It's now possible to launch containers via heat SoftwareConfig
resources in much the same way as we currently apply puppet manifests.

I'm also aware there has been some great work going on around the kolla
community making things work well with both docker-compose and atomic.

I'm interested in discussing the next steps, which would appear to involve
providing an optional way to deploy services via containers using TripleO.

It seems that we can potentially build on the existing abstractions which
were added for puppet integration, e.g:

https://github.com/openstack/tripleo-heat-templates/blob/master/overcloud-resource-registry-puppet.yaml

We could have an alternative resource-registry which maps in a different
set of templates (which have the same parameter interfaces) which bootstrap
a container host, and deploy each service in a container.

This might look something like:

https://github.com/hardys/heat-templates/blob/docker-host/hot/software-config/example-templates/example-docker-script.yaml

This is just a simple example using "docker run", but similar (probably
much cleaner) approaches will be possible using atomic, docker-compose and
other tools.

For example, here's an example of how we might bootstrap a pristine atomic
image, install a privileged container hosting the agents needed to talk to
heat, then use that container to launch containers with the services:

https://review.openstack.org/#/c/164572/6/hot/software-config/example-templates/example-pristine-atomic-docker-compose.yaml

Similar example for docker-compose:

https://github.com/openstack/heat-templates/blob/master/hot/software-config/example-templates/example-docker-compose-template.yaml

There does seem to be a variety of tools folks prefer, but the pattern
appears to be the same in most cases:

1. Provide input parameters to the template
2. Map parameters to an environment consumable by the container-launching
   tool
3. Run the tool and wait for success

It may be possible to abstract the details of the various tools inside the
heat hooks, such that you could e.g choose the tool you want via a template
parameter - e.g it should be possible to build the templates in a way which
is somewhat tool-agnostic, if we get the heat interfaces refined correctly.

What do people think, is this direction reasonable?  I'm keen to figure out
how we do a simple PoC which will bottom out the details, but it'd be great
to get some feedback on the general approach.

Thanks!

Steve