On Fri, Jul 24, 2015 at 12:02 AM, Mohammad Banikazemi <m...@us.ibm.com> wrote: > "Daneyon Hansen (danehans)" <daneh...@cisco.com> wrote on 07/23/2015 > 03:40:38 PM: > >> From: "Daneyon Hansen (danehans)" <daneh...@cisco.com> >> To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@lists.openstack.org>, Mohammad Banikazemi/Watson/ >> IBM@IBMUS, "Steven Dake (stdake)" <std...@cisco.com> >> Cc: Eran Gampel <eran.gam...@toganetworks.com>, Irena Berezovsky >> <ir...@midokura.com> >> Date: 07/23/2015 03:45 PM >> Subject: Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing >> Dockers networking to Neutron >> >> From: Antoni Segura Puimedon <toni+openstac...@midokura.com> >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" < >> openstack-dev@lists.openstack.org> >> Date: Thursday, July 23, 2015 at 11:16 AM >> To: Mohammad Banikazemi <m...@us.ibm.com>, "Steven Dake (stdake)" < >> std...@cisco.com> >> Cc: Eran Gampel <eran.gam...@toganetworks.com>, "OpenStack >> Development Mailing List (not for usage questions)" <openstack- >> d...@lists.openstack.org>, Irena Berezovsky <ir...@midokura.com> >> Subject: Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing >> Dockers networking to Neutron >> >> Why is a separate OpenStack project needed to contribute to >> libnetwork? I would think the Neutron community would follow the >> libnetwork contrib guidelines and submit the code.
When I talked with the libnetwork people, my original goal being to make a libnetwork in tree driver before libnetwork was announced at Docker Con, it was made clear to me that third party network providers like weave, calico and Kuryr should be plugins for the remote driver and strictly out of tree. >> > > While there may be contributions to docker/libnetwork at some point, the > project is not about contributing to libnetwork. For example, the Neutron > driver itself won't be part of the docker or libnetwork tree. It is for what I stated above and Mohammad comes to the same conclusion as I did. The external providers must live apart from libnetwork and we must work together with other external providers in the future to better or increase the surface of the plugin interface as common usage patterns emerge and are seen as valuable by a sizable part of the libnetwork community. > Making other > OpenStack and Neutron services available for use by containers may be a good > reason for having it under the OpenStack and Neutron umbrella but I think > one can debate where a project fits best. My reason for this is that Kuryr aims to bring all the power and flexibility of the Neutron networking to Docker containers and I can't think of any community more fit to do so than the Neutron community itself. Neutron has a mature codebase that provides services that can be useful for container users. Services that are not commonly not available to them via an API as convenient and flexible as Neutron is. That is why I think that it is not just those users of Neutron that are now looking at Docker that will find Kuryr to be a natural match, but I also expect users starting to scale up and optimize their growing container deployments to find Kuryr (by its exposure of the Neutron goods) to bring them an interesting set of tools for their larger and fine tuned container based deployments. > > Best, > > Mohammad > > > __________________________________________________________________________ > 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
