On Thu, Oct 17, 2013 at 8:29 PM, Clint Byrum <[email protected]> wrote: > 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.
Well, having a first version of the driver merged into nova core is the best way to improve it over the next releases! >> 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. Being gated and wrapped in OpenStack procedures makes sense. > 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. "glorious fashion" is the right term :-). It's true that the plugin does not prevent the user to keep using docker directly (which is a good point actually). Then the plugin has to be tolerant as you describe. > 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. Taking notes :-) >> 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. -- @sam_alba _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
