[openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers
armamig at gmail.com
Sat Dec 3 04:42:23 UTC 2016
On 30 November 2016 at 02:23, Kevin Benton <kevin at benton.pub> wrote:
> >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
> * 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.
This is actually a good point worth emphasising because this might have
been unique to our situation at the time: there was an infra patch applied
to all neutron stadium projects that modified gerrit ACLs so that stable
backports would be under the control of the neutron-stable-main team.
Because of the example that Kevin described, members of the team were faced
with the paradox of having to either turn a blind eye, or try to fight the
battle of educating contributors and fixing the 'malpractice' at the root.
Now irrespective of whether the openstack stable policy is deemed too rigid
by some or not, we started to observe that within the same governance we
had individual initiatives behaving totally differently, so differently
that some of us started to wonder what the stadium was for, what was the
point of it, and whether it was misused as a marketing tool.
That's when I came up with the proposal of defining the neutron stadium as
a list of projects that behave consistently and adhere to a common set of
agreed principles, such as common backporting strategies, testing
procedures, including our ability to claim the entire technology stack to
be fully open and completely exercised with upstream infra resources: a
list of projects that any member of the neutron core team should be able to
stand behind and support it without too many ideological clashes.
It's been a long journey and we're almost at the end of it. The neutron
core team has been very supportive of this journey. Now I am not sure
whether they did that just to make me happy and will undo all of it when I
step down :) but I genuinely think it has been a great effort that allowed
us to improve what we've been building by means of setting ourselves
achievable and measurable goals.
> * 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>
>> 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
>> > >>> 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
>> I'll let someone from the Neutron team fill in the details behind their
>> decision, because I don't want to misrepresent them.
>> > cheers,
>> > Zane.
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev