<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 30 April 2016 at 14:24, Fawad Khaliq <span dir="ltr"><<a href="mailto:fawad@plumgrid.com" target="_blank">fawad@plumgrid.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"><font face="arial, helvetica, sans-serif" color="#000000" style="background-color:rgb(255,255,255)">Hi folks,<br><br>Hope everyone had a great summit in Austin and got back safe! :)<br><br>At the design summit, we had a Neutron stadium evolution session, which needs your immediate attention as it will impact many stakeholders of Neutron.<br></font></div></blockquote><div><br></div><div>It's my intention to follow up with a formal spec submission to neutron-specs as soon as I recover from the trip. Then you'll have a more transparent place to voice your concern.</div><div>  <br></div><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"><font face="arial, helvetica, sans-serif" color="#000000" style="background-color:rgb(255,255,255)"><br>To summarize for everyone, our Neutron leadership made the following proposal for the “greater-good” of Neutron to improve and reduce burden on the Neutron PTL and core team to avoid managing more Neutron drivers:<br></font></div></blockquote><div><br></div><div>It's not just about burden. It's about consistency first and foremost.</div><div> </div><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"><font face="arial, helvetica, sans-serif" color="#000000" style="background-color:rgb(255,255,255)"><br>Quoting the etherpad [1]<br><br>"No request for inclusion are accepted for projects focussed solely on implementations and/or API extensions to non-open solutions."<br></font></div></blockquote><div><br></div><div>By the way, this was brought forward and discussed way before the Summit. In fact this is already implemented at the Neutron governance level [1].</div><div> </div><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"><font face="arial, helvetica, sans-serif" color="#000000" style="background-color:rgb(255,255,255)">To summarize for everyone what this means is that all Neutron drivers, which implement non open source networking backends are instantly out of the Neutron stadium and are marked as "unofficial/unsupported/remotely affiliated" and rest are capable of being tagged as "supported/official”.<br></font></div></blockquote><div><br></div><div>Totally false.</div><div><br></div><div>All this means is that these projects do not show up in list [1] (minus [2], which I forgot): ie. these projects are the projects the Neutron team vouches for. Supportability is not a property tracked by this list. You, amongst many, should know that it takes a lot more than being part of a list to be considered a supported solution, and I am actually even surprised that you are misled/misleading by bringing 'support' into this conversation. <br></div><div><br></div><div>[1] <a href="http://governance.openstack.org/reference/projects/neutron.html" target="_blank">http://governance.openstack.org/reference/projects/neutron.html</a><br></div><div>[2] <a href="https://review.openstack.org/#/c/309618/" target="_blank">https://review.openstack.org/#/c/309618/</a></div><div> </div><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"><font face="arial, helvetica, sans-serif" color="#000000" style="background-color:rgb(255,255,255)"><br>This eliminates all commercial Neutron drivers developed for many service providers and enterprises who have deployed OpenStack successfully with these drivers. It’s unclear how the OpenStack Foundation will communicate its stance with all the users but clearly this is a huge set back for OpenStack and Neutron. Neutron will essentially become closed to all existing, non-open drivers, even if these drivers have been compliant with Neutron API for years and users have them deployed in production, forcing users to re-evaluate their options.<br></font></div></blockquote><div><br></div><div>Again, totally false.</div><div><br></div><div>The Neutron team will continue to stand behind the APIs and integration mechanisms in a way that made the journey of breaking down the codebase as we know it today possible. Any discussion of evolving these has been done and will be done in the open and with the support of all parties involved, non-open solutions included.</div><div> </div><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"><font face="arial, helvetica, sans-serif" color="#000000" style="background-color:rgb(255,255,255)"><br>Furthermore, this proposal will erode confidence in Neutron and OpenStack, and destroy much of the value that the community has worked so hard to build over the years.</font></div></blockquote><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"><font face="arial, helvetica, sans-serif" color="#000000" style="background-color:rgb(255,255,255)"><br>As a representative and member of the OpenStack community and maintainer of a Neutron driver (since Grizzly), I am deeply disappointed and disagree with this statement [2]. Tossing out all the non-open solutions is not in the best interest of the end user companies that have built working OpenStack clusters. This proposal will lead OpenStack end users who deployed different drivers to think twice about OpenStack communities’ commitment to deliver solutions they need. Furthermore, this proposal punishes OpenStack companies who developed commercial backend drivers to help end users bring up OpenStack clouds.<br></font></div></blockquote><div><br></div><div><div>What? Now you're just spreading FUD.</div></div><div><br></div><div>What is being discussed in that etherpad is totally in line with [1], which you approved and stood behind, by the way! No-one is breaking anything, we're simply better reflecting what initiatives the Neutron core team is supposed to be accountable for and, as a result, empower the individual core teams of those vendor drivers. I appreciate there might be a gap in where to describe the effort of these initiatives in [2], but I believe there's something like the marketplace [3] that's better suited for what you're after. IMO, [2] was never intended to be that place, and I stand corrected if not.</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/309618/" target="_blank">https://review.openstack.org/#/c/309618/</a><br></div><div>[2] <a href="http://governance.openstack.org/">http://governance.openstack.org/</a></div><div>[3] <a href="https://www.openstack.org/marketplace/drivers/">https://www.openstack.org/marketplace/drivers/</a></div><div><br></div><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"><font face="arial, helvetica, sans-serif" color="#000000" style="background-color:rgb(255,255,255)"><br>Also, we have to realize that this proposal divides the community rather than unifying it. If it proceeds, it seems all OpenStack projects should follow for consistency. For example, this should apply to Nova which means HyperV and vShphere can't be part of Nova, PLUMgrid can't be part of Kuryr, and ABC company cannot have a driver/plugin for a XYZ project.<br></font></div></blockquote><div><br></div><div>Every project is different, comparing Nova to Neutron or Cinder etc is not a like-for-like comparison.</div><div> </div><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"><font face="arial, helvetica, sans-serif" color="#000000" style="background-color:rgb(255,255,255)"><br>Another thing to note is, for operators, the benefit is that the flexibility up until now has allowed them to embark on successful OpenStack deployments. For those operators, yanking out support they’ve come to depend on makes things worse. While certain team members may prefer only open-source technology, it’s better to let the end users make that decision in the free competition of the marketplace without introducing notion of official/supported vs unofficial/unsupported drivers purely based on open-source nature of the driver backend despite having complete compliance with the OpenStack ecosystem.<br></font></div></blockquote><div><br></div><div>As as I said, this is not about support. Solutions will continue to work (well or badly) as they used to, even if they are no longer part of that list.</div><div><br></div><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"><font face="arial, helvetica, sans-serif" color="#000000" style="background-color:rgb(255,255,255)"><br>So if the Neutron PTL is over burdened, we should all help him somehow so he does not have to make decisions and solve problems in a way that OpenStack community breaks like this.<br><br>I hope we see people offer ideas, time to help and discuss this and that our Neutron leadership understands the points I am raising and we can avoid going towards such a route to prevent Neutron, OpenStack, and its ecosystem from expanding so we continue to see "one" OpenStack community with one open API.<br></font></div></blockquote><div><br></div><div>As I said earlier, it's my intention to follow up with a formal spec submission to neutron-specs so that we can all better articulate thoughts, and get to a more formal closure/consensus.</div><div> </div><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"><font face="arial, helvetica, sans-serif" color="#000000" style="background-color:rgb(255,255,255)"><br>[1] <a href="https://etherpad.openstack.org/p/newton-neutron-community-stadium-evolution" target="_blank">https://etherpad.openstack.org/p/newton-neutron-community-stadium-evolution</a><br>[2] "No request for inclusion are accepted for projects focussed solely on implementations and/or API extensions to non-open solutions."<br><br>Thanks,<br>Fawad Khaliq</font></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>