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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
