Open Stack

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." <armamig at gmail.com> wrote:

>
>
> 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.
>
> 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-request at 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-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/20160123/1b1318b2/attachment.html>