[openstack-dev] [Heat] Plugin to use Docker containers a resources in a template
Sam Alba
sam.alba at gmail.com
Fri Oct 18 03:51:03 UTC 2013
On Thu, Oct 17, 2013 at 7:47 PM, Steven Dake <sdake at redhat.com> 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
More information about the OpenStack-dev
mailing list