[openstack-dev] [Neutron][Kuryr][kolla] - Bringing Dockers networking to Neutron

Antoni Segura Puimedon toni+openstackml at midokura.com
Thu Jul 23 18:16:33 UTC 2015


On Thu, Jul 23, 2015 at 7:35 PM, Mohammad Banikazemi <mb at us.ibm.com> wrote:

> I let the creators of the project speak for themselves but here is my take
> on project Kuryr.
>
> The goal is not to containerize Neutron or other OpenStack services. The
> main objective is to use Neutron as a networking backend option for Docker.
> The original proposal was to do so in the context of using containers (for
> different Neutron backends or vif types). While the main objective is
> fundamental to the project, the latter (use of containers in this
> particular way) seems to be a tactical choice we need to make. I see
> several different options available to achieve the same goal in this regard.
>

Thanks Mohammad. It is as you say, the goal of Kuryr to provide Docker with
a new libnetwork remote
driver that is powered by Neutron, not a containerization of Neutron. Kuryr
deployments as you point out,
may opt to point to a Neutron that is containerized, and for that I was
looking at using Kolla. However,
that is just deployment and I consider it to be something up to the
deployer (of course, we'll make Kuryr
containerizable and part of Kolla :-) ).

The design for interaction/configuration is not yet final, as I still have
to push drafts for the blueprints and
get comments, but my initial idea is that you will configure docker to pass
the configuration of which
device to take hold of for the overlay and where the neutron api are in the
following way.

$ docker -d --kv-store=consul:localhost:8500
--label=com.docker.network.driver.kuryr.bind_interface=eth0
--label=com.docker.network.driver.kuryr.neutron_api=10.10.10.10
--label=com.docker.network.driver.kuryr.token=AUTH_tk713d067336d21348bcea1ab220965485

Another possibility is that those values were passed as env variables
or plain old configuration files.



>
> Now, there is another aspect of using containers in the context of this
> project that is more interesting at least to me (and I do not know if
> others share this view or not) and that is the use of containers for
> providing network services that are not available through libnetwork as of
> now or in near future or ever. From the talks I have had with libnetwork
> developers the plan is to stay with the basic networking infrastructure and
> leave additional features to be developed by the community and to do so
> possibly by using what else, containers.
>

> So take the current features available in libnetwork. You mainly get
> support for connectivity/isolation for multiple networks across multiple
> hosts. Now if you want to route between these networks, you have to devise
> a solution yourself. One possible solution would be having a router service
> in a container that gets connected to say two Docker networks. Whether the
> router service is implemented with the use of the current Neutron router
> services or by some other solutions is something to look into and discuss
> but this is a direction where I think Kuryr (did I spell it right? ;)) can
> and should contribute to.
>

You got that right. The idea is indeed to get the containers networked via
libnetwork that, as you point out,
was left intentionally simple to be developed by the community; then we
want to make make:

a) Kuryr get the containers to networks that have been pre-configured with
advanced networking (lb, sec groups, etc).
Being able to perform changes on those networks via neutron after the fact
as well. For example the container
orchestration software could create a Neutron network with a load balancer
and a FIP, start containers on that network
and add them to the load balancer.
b) Via the usage of either docker labels on `docker run` make Kuryr
implicitly set up Neutron networks/topologies.

Yup, you spelled it well. In Czech it is Kurýr, but for project purposes I
dropped the "´"
Thanks a lot for contributing and I'm very happy to see that you got a very
good sense for the direction we are taking.
I'm looking forward to meet you all in the community meetings!

>
> Just my 2 cents on this topic.
>
> Best,
>
> Mohammad
>
>
> [image: Inactive hide details for "Steven Dake (stdake)" ---07/23/2015
> 11:34:09 AM---Gal, I’m not clear exactly what you plan to do wi]"Steven
> Dake (stdake)" ---07/23/2015 11:34:09 AM---Gal, I’m not clear exactly what
> you plan to do with regards to building docker containers for Neutro
>
> From: "Steven Dake (stdake)" <stdake at cisco.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>, Eran Gampel <
> Eran.Gampel at toganetworks.com>, Antoni Segura Puimedon <toni at midokura.com>,
> Irena Berezovsky <irena at midokura.com>, "gal.sagie at gmail.com" <
> gal.sagie at gmail.com>
> Date: 07/23/2015 11:34 AM
> Subject: Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing Dockers
> networking to Neutron
> ------------------------------
>
>
>
> Gal,
>
> I’m not clear exactly what you plan to do with regards to building docker
> containers for Neutron, but the Kolla project has developed both
> linuxbridge and ovs agents as well as a complete running Neutron system
> inside container technology. We can launch it AIO with docker-compose, or
> alternatively it can be launched AIO or multinode with Ansible. Note we
> have a complete OpenStack implementation, not just Neutron.
>
> We would welcome additional driver support using the standard OpenStack
> gerrit workflow.
>
>
> *https://github.com/stackforge/kolla/tree/master/docker/centos/binary/neutron*
> <https://github.com/stackforge/kolla/tree/master/docker/centos/binary/neutron>
>
> Note we are also in the process of adding build from source to our tree
> here:
>
>
> *https://github.com/stackforge/kolla/tree/master/docker/centos/source/neutron*
> <https://github.com/stackforge/kolla/tree/master/docker/centos/source/neutron>
>
> For further background on Kolla, check out our wiki page:
>
> *https://wiki.openstack.org/wiki/Kolla*
> <https://wiki.openstack.org/wiki/Kolla>
>

Hi Steven,

I'm glad to see you in this thread.

The goal of Kuryr is as pointed above by Mohammad (I added a bit to it).
This other goal of getting additional
drivers for Neutron in Kolla is something that I've been looking at for a
while and, while I can only speak for MidoNet,
I think it is something that all of the Neutron vendors should be looking
to provide

I have been playing with kolla a bit and I have it on my list to have a
Neutron container with the MidoNet plugin
and a nova compute container with the MidoNet Host Agent. I'll be reaching
out on irc for help with that ;-)


Best regards,

Antoni Segura Puimedon



>
> Best wishes,
> -steve
>
> *From: *Gal Sagie <*gal.sagie at gmail.com* <gal.sagie at gmail.com>>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <*openstack-dev at lists.openstack.org*
> <openstack-dev at lists.openstack.org>>
> *Date: *Wednesday, July 22, 2015 at 9:28 AM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> *openstack-dev at lists.openstack.org* <openstack-dev at lists.openstack.org>>,
> Eran Gampel <*Eran.Gampel at toganetworks.com* <Eran.Gampel at toganetworks.com>>,
> Antoni Segura Puimedon <*toni at midokura.com* <toni at midokura.com>>, Irena
> Berezovsky <*irena at midokura.com* <irena at midokura.com>>
> *Subject: *[openstack-dev] [Neutron][Kuryr] - Bringing Dockers networking
> to Neutron
>
>
>       Hello Everyone,
>
>       Project Kuryr is now officially part of Neutron's big tent.
>       Kuryr is aimed to be used as a generic docker remote driver that
>       connects docker to Neutron API's
>       and provide containerised images for the common Neutron plugins.
>       We also plan on providing common additional networking services
>       API's from other sub projects
>       in the Neutron big tent.
>
>       We hope to get everyone on board with this project and leverage
>       this joint effort for the many different solutions out there (instead of
>       everyone re-inventing the wheel for each different project).
>
>       We want to start doing a weekly IRC meeting to coordinate the
>       different requierments and
>       tasks, so anyone that is interested to participate please share
>       your time preference
>       and we will try to find the best time for the majority.
>
>       Remember we have people in Europe, Tokyo and US, so we won't be
>       able to find time that fits
>       everyone.
>
>       The currently proposed time is *Wedensday at 16:00 UTC *
>
>       Please reply with your suggested time/day,
>       Hope to see you all, we have an interesting and important project
>       ahead of us
>
>       Thanks
>       Gal.
>       __________________________________________________________________________
>       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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150723/393915ae/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150723/393915ae/attachment.gif>


More information about the OpenStack-dev mailing list