Open Stack

Excerpts from Andrew Plunk's message of 2014-05-20 13:49:58 -0700:
> No Problem.
> 
> As the Docker resource in Heat currently works, it will require Docker running on a customer's vm to listen over a network socket. With software config you could allow Docker to listen on the instance's local unix socket, and communicate with Docker via Heat's in instance software config agents.
> 

This would effectively make Docker another case of "syntactic sugar",
much like OS::SoftwareConfig::Chef would be.

Short term I think this will get Docker onto Heat users' instances
quicker.

However I do think that the limitations of this approach are pretty
large, such as how to model the network in such a way where we could
attach a floating IP to a container running in a VM. There's a lot of
extra plumbing that gets shrugged off to user-managed hosts that seems
like a generic nesting interface that would be useful for things like
TripleO too where we want to nest a VM inside the deployment cloud.

Anyway, the local socket is the way to go. The less we teach Heat's
engine to reach out to non-OpenStack API's, the more we can keep it
isolated from hostile entities.