Open Stack

>This would effectively make Docker another case of "syntactic sugar",
>much like OS::SoftwareConfig::Chef would be.

>Short term I think this will get Docker onto Heat users' instances
>quicker.

Agreed.

>However I do think that the limitations of this approach are pretty
>large, such as how to model the network in such a way where we could
>attach a floating IP to a container running in a VM. There's a lot of
>extra plumbing that gets shrugged off to user-managed hosts that seems
>like a generic nesting interface that would be useful for things like
>TripleO too where we want to nest a VM inside the deployment cloud.


I do not think limiting the Docker api to listening to a unix socket

on a compute instance would stop one from being able to attach a
floating ip to a container running in a VM. One would have to start
the docker container mapped to a port on the host vm that was not
firewalled. Docker already has support for mapping host to container
ports, so the software config agent would have to just pass those options
along.

-Andrew

On 5/20/14 4:16 PM, "andrew plunk" <andrewdevplu at gmail.com> wrote:
>Excerpts from Andrew Plunk's message of 2014-05-20 13:49:58 -0700:
>> No Problem.
>>
>> As the Docker resource in Heat currently works, it will require Docker
>>running on a customer's vm to listen over a network socket. With
>>software config you could allow Docker to listen on the instance's local
>>unix socket, and communicate with Docker via Heat's in instance software
>>config agents.
>>
>
>This would effectively make Docker another case of "syntactic sugar",
>much like OS::SoftwareConfig::Chef would be.
>
>Short term I think this will get Docker onto Heat users' instances
>quicker.
>
>However I do think that the limitations of this approach are pretty
>large, such as how to model the network in such a way where we could
>attach a floating IP to a container running in a VM. There's a lot of
>extra plumbing that gets shrugged off to user-managed hosts that seems
>like a generic nesting interface that would be useful for things like
>TripleO too where we want to nest a VM inside the deployment cloud.
>
>Anyway, the local socket is the way to go. The less we teach Heat's
>engine to reach out to non-OpenStack API's, the more we can keep it
>isolated from hostile entities.
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev