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