I agree with Armando and feel option 2 would be viable if we really want to deliver this feature in Mitaka time frame. Adding a new stadium project invites more work and can be done in N release.
Thanks Vikram On Jan 22, 2016 11:47 PM, "Armando M." <arma...@gmail.com> wrote: > > > On 22 January 2016 at 08:57, Tidwell, Ryan <ryan.tidw...@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. > > Cheers, > Armando > > [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-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 > >
__________________________________________________________________________ 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
