Open Stack

>I'll let someone from the Neutron team fill in the details behind their decision,
because I don't want to misrepresent them.

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:

* Releases and stable branches:
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.


* Pass-through drivers:
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.

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.

* Changes impossible to judge for cores:
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. So reviewing driver changes became somewhat of a rubber stamping
process that many were not interested in and/or comfortable doing.


>I hope I'm not the only one who thinks drivers are important?

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?

On Tue, Nov 29, 2016 at 11:08 AM, Doug Hellmann <doug at doughellmann.com>
wrote:

> Excerpts from Zane Bitter's message of 2016-11-29 12:36:03 -0500:
> > On 29/11/16 10:28, Doug Hellmann wrote:
> > > Excerpts from Chris Friesen's message of 2016-11-29 09:09:17 -0600:
> > >> On 11/29/2016 08:03 AM, Doug Hellmann wrote:
> > >>> I'll rank my preferred solutions, because I don't actually like any
> of
> > >>> them.
> > >>
> > >> Just curious...what would you "actually like"?
> > >>
> > >> Chris
> > >>
> > >
> > > My preference is to have teams just handle the drivers voluntarily,
> > > without needing to make it a rule or provide a way to have teams
> > > that only work on a driver. That's not one of the options we proposed,
> > > but the results are like what we would get with option 6 (minus the
> > > precedent of the TC telling teams what code they must manage).
> >
> > I don't have a lot of background on why the driver was removed from the
> > Neutron stadium, but reading between the lines it sounds like you think
> > that Neutron made the Wrong Call, and that you would like, in order of
> > preference:
> >
> > a) Neutron to start agreeing with you; or
> > b) The TC to tell Neutron to agree with you; or
>
> I hope I'm not the only one who thinks drivers are important?
>
> I would prefer not to impose obligations on anyone. I wrote up that
> option to explore what it would look like, not because I think it's
> the best outcome.  At the same time, the current approach is actively
> harmful to the overall health of the community by pushing away
> contributors and useful contributions, especially considering the
> different responses to vendor-related issues in other teams.  And
> this does fall within the scope of issues and policies the TC is
> meant to manage.
>
> > c) To do an end run around Neutron by adding it as a separate project
>
> I wouldn't categorize that last one as an end-run. We wouldn't be
> adding the driver team to Neutron, we would be adding it to OpenStack.
> The Neutron team would have no more responsibility for the output of
> a driver team than they do anyone else.
>
> > Individual projects (like Neutron) have pretty wide latitude to add
> > repositories if they want, and are presumably closer to the issues than
> > anyone. So it seems strange that we're starting with a discussion about
> > how to override their judgement, rather than one about why we think
> > that's necessary.
>
> I did, in the original post, try to explain why I think it's necessary.
>
>   The OpenStack community wants to encourage collaboration by
>   emphasizing contributions to projects that abstract differences
>   between vendor-specific products, while still empowering vendors
>   to integrate their products with OpenStack through drivers that
>   can be consumed by the abstraction layers
>
> In addition to wanting collaboration between experts in a given
> field, projects support drivers to give deployers choices. Encouraging
> vendors to write drivers furthers both goals. It also encourages
> those same vendors to be active in the community in other ways,
> such as sponsoring events and the Foundation. Whether we achieve
> *that* goal depends on a lot of factors, and we're more successful
> with some vendors than others. Turning away contributions does not
> encourage their participation in any way I can understand.
>
> > What are the obstacles to the Neutron team agreeing to host these
> > drivers? Perhaps the TC is in a position to remove some of those
> > obstacles? That seems preferable to imposing new obligations on projects.
>
> I'll let someone from the Neutron team fill in the details behind their
> decision, because I don't want to misrepresent them.
>
> Doug
>
> >
> > cheers,
> > Zane.
> >
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161130/5c8bdb12/attachment.html>