Open Stack

Excerpts from Sam Alba's message of 2013-10-17 18:06:04 -0700:
> Hi all,
> 
> I've been recently working on a Docker plugin for Heat that makes it
> possible to use Docker containers as resources.
> 
> I've just opened the repository:
> https://github.com/dotcloud/openstack-heat-docker
> 
> It's now possible to do that via Nova (since there is now a Docker
> driver for it). But the idea here is not to replace the Nova driver
> with this Heat plugin, the idea is just to propose a different path.
> 
> Basically, Docker itself has a Rest API[1] with all features needed to
> deploy and manage containers, the Nova driver uses this API. However
> having the Nova API in front of it makes it hard to bring all Docker
> features to the user, basically everything has to fit into the Nova
> API. For instance, docker commit/push are mapped to nova snapshots,
> etc... And a lot of Docker features are not available yet; I admit
> that some of them will be hard to support (docker Env variables,
> Volumes, etc... how should they fit in Nova?).
> 

Agreed, I never thought docker was an excellent fit at the nova driver
level. It certainly seems useful, but not necessarily excellent.

> The idea of this Docker plugin for Heat is to use the whole Docker API
> directly from a template. All possible parameters for creating a
> container from the Docker API[2] can be defined from the template.
> This allows more flexibility.
>

I just looked through the README and examples quickly, and it is
fantastic. I think this is a nice example of how to integrate
a non-OpenStack component into a Heat template.

I have some thoughts on next steps:

1) Consider moving it to Heat's contrib directory. Being gated and wrapped
in OpenStack procedures means you will get more OpenStack contribution. Of
course, if your community is more at home where the repo is, then leave
it there. We don't _need_ plugins to be in contrib.

2) Docker.handle_delete will fail in glorious fashion if you have deleted
the container already from outside. We follow a general paradigm where
if the underlying components of the resource are not found, consider that
"success" and exit the handle_delete method. This also helps if a delete
failed in some other way and you are retrying the delete.

3) Would be really cool to also have a traditional Heat template that
one can nest for deploying docker itself on an OS::Nova::Server. Combine
that with the random string generator for passwords and you can have a
fully automatic Heat controlled deployment of docker things.

> Since this approach is a bit different from the normal OpenStack
> workflow (for instance, Nova's role is to abstract all computing units
> right now), I am interested to get feedback on this.
> 

This isn't all that far off from what an OS::Trove::Database resource
would be. You are encapsulating another management tool that simplifies
a common task and gives it an API into a resource to relieve people of
the need to repeat all of the API orchestration that they would have to
do in-server.