<font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2">We are very interested in spinning out BGP Dynamic Routing into a separate stadium project. We are ready and willing to help make this happen soon.<br><br>Mickey<br><br><br><font color="#990099">-----Vikram Choudhary <<a target="_blank" href="mailto:vikschw@gmail.com">vikschw@gmail.com</a>> wrote: -----</font><div class="iNotesHistory" style="padding-left:5px;"><div style="padding-right:0px;padding-left:5px;border-left:solid black 2px;">To: "OpenStack Development Mailing List (not for usage questions)" <<a target="_blank" href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>From: Vikram Choudhary <<a target="_blank" href="mailto:vikschw@gmail.com">vikschw@gmail.com</a>><br>Date: 03/21/2016 02:36AM<br>Subject: Re: [openstack-dev] [neutron] BGP Dynamic Routing Development Going Forward<br><br><div dir="ltr"><div>Hi All,</div><div><br></div>I would like to reopen this mail tread for 'N' release. It's really great that we are able to ship 'BGP Dynamic Routing' functionality as part of Mitaka. Thanks to everyone who has contributed and helped in making this a reality ;)<div><br></div><div>For 'N' cycle, couple of RFE's [1] are already being lined up. In this regard we would like to hear from the community on what will be the best way moving forward:<br></div><div><div><br></div><div>1. Spun out 'BGP Dynamic Routing functionality' as a separate stadium project?</div><div>(FYI: We already initiated this during Mitaka via [2] & [3])</div><div><br></div><div>2. Keep developing in the neutron repo till we reach to a decision?</div><div>(As we have done in Mitaka so far)</div><div><br></div><div>[1] <a href="https://bugs.launchpad.net/neutron/+bugs?field.tag=l3-bgp">https://bugs.launchpad.net/neutron/+bugs?field.tag=l3-bgp</a></div><div>[2] <a href="https://review.openstack.org/#/c/268726/">https://review.openstack.org/#/c/268726/</a></div><div>[3] <a href="https://review.openstack.org/#/c/268727/">https://review.openstack.org/#/c/268727/</a></div><div><br></div><div>Thanks</div><div>Vikram<br><div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 26, 2016 at 3:33 AM, Armando M. <span dir="ltr"><<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On 25 January 2016 at 08:23, Tidwell, Ryan <span dir="ltr"><<a href="mailto:ryan.tidwell@hpe.com" target="_blank">ryan.tidwell@hpe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri,sans-serif;"><font color="#1f497d">Responses inline<u></u><u></u></font></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri,sans-serif;"><font color="#1f497d"><u></u> <u></u></font></span></p><p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif"> Gal Sagie [mailto:<a href="mailto:gal.sagie@gmail.com" target="_blank">gal.sagie@gmail.com</a>]
<br><b>Sent:</b> Friday, January 22, 2016 9:49 PM<br><b>To:</b> OpenStack Development Mailing List (not for usage questions)<br><b>Subject:</b> Re: [openstack-dev] [neutron] BGP Dynamic Routing Development Going Forward<u></u><u></u></span></p><p class="MsoNormal"><u></u> <u></u></p><div><span><p class="MsoNormal">The real question that needs to be asked (at least for me) is how this feature can work with other plugins/ML2 drivers<u></u><u></u></p><div><p class="MsoNormal">that are not the reference implementation.<u></u><u></u></p></div></span><div><p class="MsoNormal"><font color="#1f497d"><u></u> <u></u></font></p><p style="margin-left:0in;text-indent:0in"><u></u><span style="font-size: 11pt; font-family: Calibri,sans-serif;"><font color="#1f497d"><span>-<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></font></span><u></u><span style="font-size: 11pt; font-family: Calibri,sans-serif;"><font color="#1f497d">Regardless of the ML2 drivers you use, ML2 is supported with the reference implementation. The code we have only works with ML2 though, which is a
concern for putting this in the main repo.<u></u><u></u></font></span></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri,sans-serif;"><font color="#1f497d"><u></u> <u></u></font></span></p></div><span><div><p class="MsoNormal">How hard (possible) it is to take the API part (or maybe even the agent) and use that in another Neutron implementation.<u></u><u></u></p></div></span><div><span><p class="MsoNormal">Then focus on which ever option that works best to achieve this.<font color="#1f497d"><u></u><u></u></font></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri,sans-serif;"><font color="#1f497d"><u></u> <u></u></font></span></p></span><p><u></u><span style="font-size: 11pt; font-family: Calibri,sans-serif;"><font color="#1f497d"><span>-<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></font></span><u></u><span style="font-size: 11pt; font-family: Calibri,sans-serif;"><font color="#1f497d">The agent is actually very portable in my opinion. The server-side code is not so portable, as mentioned above only ML2 is supported. Identifying
next-hops is done by querying the DB, it’s hard to make that portable between plugins.<u></u><u></u></font></span></p></div><span><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">I personally think that if the long term goal is to have this in a separate repo then this should happen right now.<u></u><u></u></p></div><div><p class="MsoNormal">"We will do this later" just won't work, it will be harder and it will just not happen (or it will cause a lot of pain to people<u></u><u></u></p></div><div><p class="MsoNormal">that started deploying this)<u></u><u></u></p></div></span><div><span><p class="MsoNormal">At least thats my opinion, of course it depends a lot on the people who actually work on this...<u></u><u></u></p><p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri,sans-serif;"><font color="#1f497d"><u></u> <u></u></font></span></p></span><p style="margin-left:0in;text-indent:0in"><u></u><span style="font-size: 11pt; font-family: Calibri,sans-serif;"><font color="#1f497d"><span>-<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></font></span><u></u><span style="font-size: 11pt; font-family: Calibri,sans-serif;"><font color="#1f497d">I completely agree which is why I’m not too excited about deferring a split. It doesn’t really set us back in our development efforts to move out to
a separate repo. We’re quickly closing in on being functionally complete and this code peels out of the main repo rather cleanly, so I feel we really lose nothing by just moving to out of the main repo immediately if that’s the direction we go for the long
haul. As you point out it saves users some pain in during a future upgrade.</font></span></p></div></div></div></div></blockquote><div><br></div></span><div>In my humble opinion, you should get yourselves be guided by the ones who have the most hands-on experience with the Neutron codebase. By all means, we do make mistakes, but we're the ones who have been dealing with the hurdles caused by those mistakes. If we advised you for a strategy, then this strategy is most likely the direct consequence of a past/ongoing experience; if you continue ignoring this simple fact in your judgement, then this discussion is pointless.</div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div link="blue" vlink="purple" lang="EN-US"><div><div><div><p style="margin-left:0in;text-indent:0in"><span style="font-size: 11pt; font-family: Calibri,sans-serif;"><font color="#1f497d"><u></u><u></u></font></span></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Gal.<u></u><u></u></p></div></div><div><div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Sat, Jan 23, 2016 at 2:15 AM, Vikram Choudhary <<a href="mailto:vikschw@gmail.com" target="_blank">vikschw@gmail.com</a>> wrote:<u></u><u></u></p><blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><p>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.<u></u><u></u></p><p>Thanks <br><span><font color="#888888">Vikram </font></span><u></u><u></u></p><div><div><div><p class="MsoNormal">On Jan 22, 2016 11:47 PM, "Armando M." <<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>> wrote:<u></u><u></u></p><blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On 22 January 2016 at 08:57, Tidwell, Ryan <<a href="mailto:ryan.tidwell@hpe.com" target="_blank">ryan.tidwell@hpe.com</a>> wrote:<u></u><u></u></p><blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><div><div><p class="MsoNormal">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:<br><br>1. Continue with development in the main repo without any intention of spinning out to a stadium project<u></u><u></u></p><p class="MsoNormal">2. Continue on the current development course for Mitaka while targeting a spin-out to a stadium project during the N cycle<u></u><u></u></p><p class="MsoNormal">3. Spin out to a stadium project immediately<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">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.<u></u><u></u></p></div></div></blockquote><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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 :/<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Cheers,<u></u><u></u></p></div><div><p class="MsoNormal">Armando<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">[1] <a href="https://review.openstack.org/#/c/268727/" target="_blank">https://review.openstack.org/#/c/268727/</a><u></u><u></u></p></div><div><p class="MsoNormal">[2] <a href="https://review.openstack.org/#/c/268726/" target="_blank">https://review.openstack.org/#/c/268726/</a><u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><div><div><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">-Ryan<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal"><a href="https://review.openstack.org/#/c/201621/" target="_blank">https://review.openstack.org/#/c/201621/</a><u></u><u></u></p><p class="MsoNormal"><a href="https://review.openstack.org/#/q/topic:bp/bgp-dynamic-routing" target="_blank">https://review.openstack.org/#/q/topic:bp/bgp-dynamic-routing</a><u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p></div></div><p class="MsoNormal" style="margin-bottom:12pt"><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><u></u><u></u></p></blockquote></div><p class="MsoNormal"><u></u> <u></u></p></div></div><p class="MsoNormal" style="margin-bottom:12pt"><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><u></u><u></u></p></blockquote></div></div></div><p class="MsoNormal" style="margin-bottom:12pt"><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><u></u><u></u></p></blockquote></div><p class="MsoNormal"><br><br clear="all"><u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal">-- <u></u><u></u></p><div><p class="MsoNormal">Best Regards ,<br><br>The G. <u></u><u></u></p></div></div></div></div></div></div>
<br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br><br></blockquote></div></div></div><br></div></div><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br><br></blockquote></div><br></div></div></div></div></div></div><div><font face="Courier New,Courier,monospace" size="2">__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a target="_blank" href="mailto:OpenStack-dev-request@lists.openstack.org?subject">OpenStack-dev-request@lists.openstack.org?subject</a>:unsubscribe<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></font></div></div></div></font><BR>