[openstack-dev] [neutron] BGP Dynamic Routing Development Going Forward

Armando M. armamig at gmail.com
Fri Jan 22 18:12:55 UTC 2016

On 22 January 2016 at 08:57, Tidwell, Ryan <ryan.tidwell at hpe.com> wrote:

> I wanted to raise the question of whether to develop BGP dynamic routing
> in the Neutron repo or spin it out to as a stadium project.  This question
> has been raised recently on reviews and in offline discussions.  For those
> unfamiliar with this work, BGP efforts in Neutron entail admin-only API’s
> for configuring and propagating BGP announcements of next-hops for floating
> IP’s, tenant networks, and host routes for each compute port when using
> DVR.  As we are getting late in the Mitaka cycle, I would like to be sure
> there is consensus on the approach for Mitaka.  As I see it, we have 3
> courses of action:
> 1. Continue with development in the main repo without any intention of
> spinning out to a stadium project
> 2. Continue on the current development course for Mitaka while targeting a
> spin-out to a stadium project during the N cycle
> 3. Spin out to a stadium project immediately
> Each has pros and cons.  This question seems to have arisen while looking
> at the sheer amount code being proposed, its place in the Neutron model,
> and questioning whether we really want to bring that code into Neutron.  As
> such, continuing with option 1 definitely requires us to come to some
> consensus.  Let me be clear that I’m not opposed to any of these options,
> I’m simply looking for some guidance.  With that said, if the end game is a
> stadium project I do question whether #2 makes sense.

Not sure if you followed the latest discussion on [1,2] ([1] capturing the
latest events). Delivering something production worthy goes a lot more
beyond simply posting code upstream. We, as a community, have promised to
deliver BGP capabilities for many cycles, and failed so far. Choosing 3 is
clearly going to defer this to N or even O because of the amount of effort
required to set it all up (release, docs, testing, etc). Option 2, as
painful as it may sound, gives us the ability to get immediate access to
all that's required to deliver something to users so that they can play
with it at the end of Mitaka if they choose to. In the meantime that will
give us some breathing room to get ready as soon as N opens up.

I am operating under the assumption that what you guys have been working on
is close to being functionally complete. If we don't even have that, then
we're in trouble no matter which option we choose and we can defer this yet
again :/

Having said that, we can all agree that option #1 is not what we all want.
Just to be clear, I am in favor of #2.


[1] https://review.openstack.org/#/c/268727/
[2] https://review.openstack.org/#/c/268726/

> -Ryan
> https://review.openstack.org/#/c/201621/
> https://review.openstack.org/#/q/topic:bp/bgp-dynamic-routing
> __________________________________________________________________________
> 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/20160122/7f33f355/attachment.html>

More information about the OpenStack-dev mailing list