Open Stack

On 10/18/2013 05:16 PM, Sam Alba wrote:
> On Thu, Oct 17, 2013 at 8:29 PM, Clint Byrum <clint at 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