Were we looking at the same etherpad? I think the ‘inclusion criteria’ and ‘benefits of the proposal’ sections cover those two points. Are you referring to something else?
Thanks, doug > On May 2, 2016, at 12:18 PM, Gal Sagie <gal.sa...@gmail.com> wrote: > > Maybe it can help if instead of trying to define criteria to which projects > dont fit into > the stadium, try to define in your spec what IT IS, and for what purpose its > there. > > > On Mon, May 2, 2016 at 8:53 PM, Kyle Mestery <mest...@mestery.com > <mailto:mest...@mestery.com>> wrote: > On Mon, May 2, 2016 at 12:22 PM, Armando M. <arma...@gmail.com > <mailto:arma...@gmail.com>> wrote: > > > > > > On 30 April 2016 at 14:24, Fawad Khaliq <fa...@plumgrid.com > > <mailto:fa...@plumgrid.com>> wrote: > >> > >> Hi folks, > >> > >> Hope everyone had a great summit in Austin and got back safe! :) > >> > >> At the design summit, we had a Neutron stadium evolution session, which > >> needs your immediate attention as it will impact many stakeholders of > >> Neutron. > > > > > > 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. > > > >> > >> > >> 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: > > > > > > It's not just about burden. It's about consistency first and foremost. > > > >> > >> > >> Quoting the etherpad [1] > >> > >> "No request for inclusion are accepted for projects focussed solely on > >> implementations and/or API extensions to non-open solutions." > > > > > > 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]. > > > >> > >> 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”. > > > > > > Totally false. > > > > 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. > > > > [1] http://governance.openstack.org/reference/projects/neutron.html > > <http://governance.openstack.org/reference/projects/neutron.html> > > [2] https://review.openstack.org/#/c/309618/ > > <https://review.openstack.org/#/c/309618/> > > > >> > >> > >> 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. > > > > > > Again, totally false. > > > > 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. > > > >> > >> > >> 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. > >> > >> > >> 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. > > > > > > What? Now you're just spreading FUD. > > > > 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. > > > > [1] https://review.openstack.org/#/c/309618/ > > <https://review.openstack.org/#/c/309618/> > > [2] http://governance.openstack.org/ <http://governance.openstack.org/> > > [3] https://www.openstack.org/marketplace/drivers/ > > <https://www.openstack.org/marketplace/drivers/> > > > To further support Armando here, I agree that the marketplace is the > best place to host these drivers. In fact, Thierry and I briefly > discussed this, and I think advocating for the Foundation to help put > in place more of a specific drivers program and manage it makes a lot > of sense, especially as most of the benefits both developers and users > are looking for here are more around marketing and consistency. > > Thanks, > Kyle > > >> > >> 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. > > > > > > Every project is different, comparing Nova to Neutron or Cinder etc is not a > > like-for-like comparison. > > > >> > >> > >> 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. > > > > > > 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. > > > >> > >> 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. > >> > >> 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. > > > > > > 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. > > > >> > >> > >> [1] > >> https://etherpad.openstack.org/p/newton-neutron-community-stadium-evolution > >> > >> <https://etherpad.openstack.org/p/newton-neutron-community-stadium-evolution> > >> [2] "No request for inclusion are accepted for projects focussed solely on > >> implementations and/or API extensions to non-open solutions." > >> > >> Thanks, > >> Fawad Khaliq > >> > >> __________________________________________________________________________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > > > > -- > Best Regards , > > The G. > __________________________________________________________________________ > 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