<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><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><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><br>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><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><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.<br><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><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><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><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><br>[1] <a href="https://etherpad.openstack.org/p/newton-neutron-community-stadium-evolution">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>