<div dir="ltr">><span style="font-size:12.8px">I'll let someone from the Neutron team fill in the details behind their </span><span style="font-size:12.8px">decision, because I don't want to misrepresent them.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I can shed a bit of light on this since I'm a core and had been working for a driver vendor at the time of the split. There were a few areas of contention:</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">* Releases and stable branches:</span></div><div><span style="font-size:12.8px">Vendors develop features for their driver and want them available to all of their customers immediately after they do their own QA. Additionally, they want them available to the customers running security-only and even EOL branches. This obviously violates the release process for upstream openstack stuff, so terrible, terrible things were done to apply patches to these old branches at customer sites.</span></div><div><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">* Pass-through drivers:</span></div><div><span style="font-size:12.8px">In response to the issue above, many vendors ended up creating 'vendor-lib' or an HTTP/RPC API to which their Neutron in-tree driver would just pass every call with as little logic as possible. When drivers went this direction, we could never tell their current functioning state because we were always one vendor release (of either vendor-lib or vendor HTTP API) away from them breaking something.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">IIRC there was a design session in the summit about Cinder having this problem. They were trying to determine how thin a driver was allowed to be before the cores would refuse to accept it. I don't think they reached a consensus on what the limit is or if there should even be a limit.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">* Changes impossible to judge for cores:</span></div><div><span style="font-size:12.8px">For the logic changes that do occur in tree, cores could only really tell if they looked like correct python and appeared to do something sane at a very high level. Judging if the change even worked was entirely dependent on a good 3rd-party CI response. Judging things like backwards compatibility with older vendor backends was completely out of the question because no vendor offered a full matrix CI test with every version of their product. </span><span style="font-size:12.8px">So reviewing driver changes became somewhat of a rubber stamping process that many were not interested in and/or comfortable doing.</span></div><div><span style="font-size:12.8px"><br></span></div><div><br></div><div>><span style="font-size:12.8px">I hope I'm not the only one who thinks drivers are important?</span></div><div><br></div><div>Of course we care about drivers (see neutron-lib effort). However, it wasn't clear what the point of having them in tree was when cores couldn't reason about the changes or even try them without special-purpose hardware. How do you foresee the drivers improving if we bring them back in tree?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 29, 2016 at 11:08 AM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Zane Bitter's message of 2016-11-29 12:36:03 -0500:<br>
<span class="">> On 29/11/16 10:28, Doug Hellmann wrote:<br>
> > Excerpts from Chris Friesen's message of 2016-11-29 09:09:17 -0600:<br>
> >> On 11/29/2016 08:03 AM, Doug Hellmann wrote:<br>
> >>> I'll rank my preferred solutions, because I don't actually like any of<br>
> >>> them.<br>
> >><br>
> >> Just curious...what would you "actually like"?<br>
> >><br>
> >> Chris<br>
> >><br>
> ><br>
> > My preference is to have teams just handle the drivers voluntarily,<br>
> > without needing to make it a rule or provide a way to have teams<br>
> > that only work on a driver. That's not one of the options we proposed,<br>
> > but the results are like what we would get with option 6 (minus the<br>
> > precedent of the TC telling teams what code they must manage).<br>
><br>
> I don't have a lot of background on why the driver was removed from the<br>
> Neutron stadium, but reading between the lines it sounds like you think<br>
> that Neutron made the Wrong Call, and that you would like, in order of<br>
> preference:<br>
><br>
> a) Neutron to start agreeing with you; or<br>
> b) The TC to tell Neutron to agree with you; or<br>
<br>
</span>I hope I'm not the only one who thinks drivers are important?<br>
<br>
I would prefer not to impose obligations on anyone. I wrote up that<br>
option to explore what it would look like, not because I think it's<br>
the best outcome.  At the same time, the current approach is actively<br>
harmful to the overall health of the community by pushing away<br>
contributors and useful contributions, especially considering the<br>
different responses to vendor-related issues in other teams.  And<br>
this does fall within the scope of issues and policies the TC is<br>
meant to manage.<br>
<span class=""><br>
> c) To do an end run around Neutron by adding it as a separate project<br>
<br>
</span>I wouldn't categorize that last one as an end-run. We wouldn't be<br>
adding the driver team to Neutron, we would be adding it to OpenStack.<br>
The Neutron team would have no more responsibility for the output of<br>
a driver team than they do anyone else.<br>
<span class=""><br>
> Individual projects (like Neutron) have pretty wide latitude to add<br>
> repositories if they want, and are presumably closer to the issues than<br>
> anyone. So it seems strange that we're starting with a discussion about<br>
> how to override their judgement, rather than one about why we think<br>
> that's necessary.<br>
<br>
</span>I did, in the original post, try to explain why I think it's necessary.<br>
<span class=""><br>
  The OpenStack community wants to encourage collaboration by<br>
  emphasizing contributions to projects that abstract differences<br>
  between vendor-specific products, while still empowering vendors<br>
  to integrate their products with OpenStack through drivers that<br>
  can be consumed by the abstraction layers<br>
<br>
</span>In addition to wanting collaboration between experts in a given<br>
field, projects support drivers to give deployers choices. Encouraging<br>
vendors to write drivers furthers both goals. It also encourages<br>
those same vendors to be active in the community in other ways,<br>
such as sponsoring events and the Foundation. Whether we achieve<br>
*that* goal depends on a lot of factors, and we're more successful<br>
with some vendors than others. Turning away contributions does not<br>
encourage their participation in any way I can understand.<br>
<span class=""><br>
> What are the obstacles to the Neutron team agreeing to host these<br>
> drivers? Perhaps the TC is in a position to remove some of those<br>
> obstacles? That seems preferable to imposing new obligations on projects.<br>
<br>
</span>I'll let someone from the Neutron team fill in the details behind their<br>
decision, because I don't want to misrepresent them.<br>
<span class="HOEnZb"><font color="#888888"><br>
Doug<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> cheers,<br>
> Zane.<br>
><br>
<br>
______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>