On 10/18/2013 05:16 PM, Sam Alba wrote: > On Thu, Oct 17, 2013 at 8:29 PM, Clint Byrum <cl...@fewbar.com> 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! > I'm very keen to use docker from heat via 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. >>> >> 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. I'd be happy for this to live in heat/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. > "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. This would be fun to play with in the short term, but right now I'm struggling to see viable production scenarios. Heat still needs keystone and I assume Docker has no auth. Our server agent tools assume cloud-init and a nova metadata server, on the other hand many assumptions change when you're never sitting around waiting for servers to boot or packages to install.
I'm not trying to sound negative - I just don't know where this is going but I want to go there anyway! cheers _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev