Open Stack

Excerpts from Kevin Benton's message of 2016-11-30 03:23:04 -0700:
> >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:

Thanks, Kevin, it's very helpful to have these points laid out.

> * 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.

Drivers can use either the cycle-with-intermediary or independent
release models and have releases at any point within a cycle, so
that's an easy one to solve.

The new driverfixes/ branch type, created as a result of the cinder
team's need for something similar to what you describe here, should
solve the other issue of maintaining support for drivers beyond the
normal EOL point for a stable branch.

> * 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.

This I do agree is a problem. A pass-through driver provides less value
because it doesn't allow the community to collaborate on the development
of the driver itself, unless the other components are also open sourced.

> * 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.

This strikes me as an "ownership" issue, in the sense that the
Neutron team feels a sense of ownership of something that they are
too far away from to also feel pride in managing. That's an
understandable tension, and the solution is to let go of the ownership
and let the people close to the code handle it.

If the drivers are out of tree, in a separate repo under the main
team's umbrella, the core reviewers could delegate management of
the code to a subteam and not worry about handling reviews. Clearly
documenting who "owns" each driver and where to go for support, to
file bugs, etc. should go hand-in-hand with this organization, just
like it does for OpenStack as a whole.

> >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.

Yes, of course. My comment was in response to Zane's hyperbolic and
inflammatory rhetoric, nothing else.

> How do you foresee the drivers improving if we bring them back in tree?

I'm not asking you to bring the drivers in-tree. I'm asking you to
bring them back under the umbrella of repositories which are part
of the neutron team.  And I have no idea if the code quality will
change; that's not the point. The point is to encourage more general
collaboration by being welcoming to the human beings who are trying
to contribute to OpenStack.

By all means, let's set some boundaries (no pass-through drivers
would be a good one, so would having some sort of third-party CI
testing their driver), but let's not exclude people from contributing
out of hand.

Doug