Open Stack

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!

>> 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