[openstack-dev] [Neutron][Kuryr][kolla] - Bringing Dockers networking to Neutron
samuel at yaple.net
Thu Jul 23 18:37:12 UTC 2015
This is great news! I can see our two projects working close together since
we have aligned but not entirely overlapping goals.
Antoni, please reach out on IRC at any time. #kolla is active almost 24/7
due to all of our different timezones. There is usually two cores talking
at any given time. I would love to help you add MidoNet in!
On Thu, Jul 23, 2015 at 1:16 PM, Antoni Segura Puimedon <
toni+openstackml at midokura.com> wrote:
> On Thu, Jul 23, 2015 at 7:35 PM, Mohammad Banikazemi <mb at us.ibm.com>
>> 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
> 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.
>> [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
>> 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.
>> Note we are also in the process of adding build from source to our tree
>> For further background on Kolla, check out our wiki page:
> 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,
>> *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
>> 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
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 105 bytes
Desc: not available
More information about the OpenStack-dev