On Thu, Oct 17, 2013 at 7:47 PM, Steven Dake <[email protected]> wrote: > On 10/17/2013 06:06 PM, Sam Alba wrote: >> >> 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?). >> >> 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. >> >> 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. >> >> Obviously, I'll keep maintaining the Docker driver for Nova and I'm >> also working on putting together some new features I'll propose for >> the next release. >> >> >> [1] http://docs.docker.io/en/latest/api/docker_remote_api_v1.5/ >> [2] >> http://docs.docker.io/en/latest/api/docker_remote_api_v1.5/#create-a-container >> > Why not submit the resource plugin as a patch against heat using the > standard OpenStack workflow vs a separate repository?
I don't know if it makes sense at this stage. But at some point why not, I am not against submitting this upstream... What do you think? -- @sam_alba _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
