Open Stack

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