[openstack-dev] [Neutron] New Neutron subproject for a Neutron backed Docker remote networking driver
Antoni Segura Puimedon
toni+openstackml at midokura.com
Thu Jul 9 23:18:36 UTC 2015
Hi Russell and Gurucharan,
On Thu, Jul 9, 2015 at 5:09 PM, Gurucharan Shetty <shettyg at nicira.com> wrote:
> Yes. Though the code that I have has been mostly written with OVN and
> Open vSwitch in mind, it uses Neutron APIs and integrates well with
> OpenStack. The docker plugin code that I have currently uses "no-auth"
> mode of Neutron, but there is no reason for it to not work with "auth"
> (as shown in https://github.com/shettyg/ovn-docker/blob/master/ovn-container).
> The concern that I have is mostly around where to store passwords and
> how to store them.
>From a 2 min look, this seems to wrap docker commands instead of using
the new plugin
framework. However, the entities that it exposes look very, very
similar to those
in the docker Container Network Model and it would benefit from using the plugin
framework.
I would very much welcome to join efforts so that we define a vendor neutral,
Neutron based generic container that provides the container Network plumbing
using the plugin framework.
The idea is that users will be able to create and use the networks
from the docker
API, but they will also be able to query about the networks, endpoints/ports and
do operations with them talking to the container (or external) neutron server).
Regards,
Toni
>
> On Thu, Jul 9, 2015 at 7:54 AM, Russell Bryant <rbryant at redhat.com> wrote:
>> On 07/09/2015 04:55 AM, Antoni Segura Puimedon wrote:
>>> Hi list,
>>>
>>> As the subject says, we are starting a new Neutron subproject that
>>> aims to service the Docker Container Network Model[1] by leveraging
>>> Neutron in a way similar to how Nova does.
>>>
>>> So far, while we set up a subproject, we have a repo[2] where you can
>>> see a bit more explanation about what the goals are. The idea is that
>>> we'd have different Docker plumbing (connecting the Docker instances
>>> into the overlay) images for different l2 agents.For example, we'd
>>> have
>>>
>>> neutron/project_name:ovs
>>> and
>>> neutron/project_name:midonet
>>>
>>> When you'd start one of those docker images (there'll be shell scripts
>>> for starting them with what they require and also probably a sample
>>> systemd service), it will register with docker and create Neutron
>>> networks and port types with the image flavor (ovs|midonet in the
>>> example above).
>>>
>>> So far the project is nameless. I'd like to have some proposed names
>>> so that we can vote and create the subproject.
>>>
>>>
>>> Names:
>>> Kuryr - Czech name for Courier since it is delivering networking to
>>> containers. v: apuimedo+1
>>>
>>>
>>> [1] https://github.com/docker/docker/blob/master/experimental/networking.md
>>> [2] https://github.com/celebdor/neutron-docker-plugin
>>
>> On a related note, there has been some work to integrate OVN with docker
>> networking. This integration uses Neutron to handle IPAM.
>>
>> http://openvswitch.org/pipermail/dev/2015-June/056669.html
>> https://github.com/shettyg/ovn-docker
>>
>> So, there's probably some collaboration opportunity here. Most of it
>> seems like it would be the same, except maybe some minor differences in
>> getting the containers plugged into the network.
>>
>> --
>> Russell Bryant
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list