Open Stack

On Fri, Jul 24, 2015 at 12:02 AM, Mohammad Banikazemi <mb at us.ibm.com> wrote:
> "Daneyon Hansen (danehans)" <danehans at cisco.com> wrote on 07/23/2015
> 03:40:38 PM:
>
>> From: "Daneyon Hansen (danehans)" <danehans at cisco.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>, Mohammad Banikazemi/Watson/
>> IBM at IBMUS, "Steven Dake (stdake)" <stdake at cisco.com>
>> Cc: Eran Gampel <Eran.Gampel at toganetworks.com>, Irena Berezovsky
>> <irena at 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+openstackml at midokura.com>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev at lists.openstack.org>
>> Date: Thursday, July 23, 2015 at 11:16 AM
>> To: Mohammad Banikazemi <mb at us.ibm.com>, "Steven Dake (stdake)" <
>> stdake at cisco.com>
>> Cc: Eran Gampel <Eran.Gampel at toganetworks.com>, "OpenStack
>> Development Mailing List (not for usage questions)" <openstack-
>> dev at lists.openstack.org>, Irena Berezovsky <irena at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>