On Thu, Jul 23, 2015 at 7:35 PM, Mohammad Banikazemi <m...@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)" <std...@cisco.com> > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org>, Eran Gampel < > eran.gam...@toganetworks.com>, Antoni Segura Puimedon <t...@midokura.com>, > Irena Berezovsky <ir...@midokura.com>, "gal.sa...@gmail.com" < > gal.sa...@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.sa...@gmail.com* <gal.sa...@gmail.com>> > *Reply-To: *"OpenStack Development Mailing List (not for usage > questions)" <*openstack-dev@lists.openstack.org* > <openstack-dev@lists.openstack.org>> > *Date: *Wednesday, July 22, 2015 at 9:28 AM > *To: *"OpenStack Development Mailing List (not for usage questions)" < > *openstack-dev@lists.openstack.org* <openstack-dev@lists.openstack.org>>, > Eran Gampel <*eran.gam...@toganetworks.com* <eran.gam...@toganetworks.com>>, > Antoni Segura Puimedon <*t...@midokura.com* <t...@midokura.com>>, Irena > Berezovsky <*ir...@midokura.com* <ir...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev