Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Mike Perez]

On 13:33 Nov 28, Doug Hellmann wrote:
> 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.
> 
> Some teams for projects that use drivers may not want to manage
> some or all of the drivers that can be consumed by their project
> because they have little insight into testing or debugging the code,
> or do not have the resources needed to manage centrally a large
> number of separate drivers. Vendors are of course free to produce
> drivers to integrate with OpenStack completely outside of the
> community, but because we value having the drivers as well as the
> more general support of vendor companies, we want to encourage a
> higher level of engagement by welcoming vendor-specific teams to
> be a part of our community governance.
> 
> Our Requirements for New Projects list [0] includes a statement
> about establishing a "level and open collaboration playing field"
> 
>   The project shall provide a level and open collaboration playing
>   field for all contributors. The project shall not benefit a single
>   vendor, or a single vendors product offerings; nor advantage
>   contributors from a single vendor organization due to access to
>   source code, hardware, resources or other proprietary technology
>   available only to those contributors.
> 
> This requirement makes it difficult to support having teams focused
> on producing a deliverable that primarily benefits a single vendor.
> So, we have some tension between wanting to collaborate and have a
> level playing field, while wanting to control the amount of driver
> code that projects have to manage.
> 
> I'm raising this as an issue because it's not just a hypothetical
> problem. The Cisco networking driver team, having been removed from
> the Neutron stadium, is asking for status as a separate official
> team [1]. I would very much like to find a way to say "yes, welcome
> (back)!"



Sorry for bringing this thread back up as I was gone for paternity leave, and
have been looking into this a bit.

I was reached out by someone at Cisco during the Ocata summit that was
interested in a Cisco driver being more recognized and official. I think a way
forward for us to be able to have an interested party in marking which drivers
are validated to work in Neutron and tested is knowing which tests need to be
tested by which driver type [1]. If we can provide Armando with more support.
I have provided some more detailed information on reviews [1][2], and I think
this will help with what some are seeking with their drivers.

[1] - https://review.openstack.org/#/c/391594
[2] - https://review.openstack.org/#/c/363709

-- 
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Doug Hellmann]

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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Thierry Carrez]

Doug Hellmann wrote:
> [...]
> 5. Consider driver teams to be a completely different animal, defined
>in drivers.yaml instead of projects.yaml (grey option) [6]
> 
>This establishes drivers as second-order objects that are necessary
>for the success of the main projects, and for which requirements
>can be loosened. It would establish a new category of team without
>the level playing-field requirement and some of the other team
>requirements that seem not to apply to driver teams because they
>are essentially a public facet of a single vendor.

Hi everyone,

Over the last weeks we made progress on the reviews, and discussed the
various options in a couple of TC meetings. At this point a majority of
TC members is leaning toward an amended version of this "grey" proposal:

https://review.openstack.org/403829

Please review and comment on it, so that we can refine it in time for
the meeting next week. Unless a major issue is raised, we'll probably
approve it then and make further adjustments as incremental changes.

Thanks!

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Steve Martinelli]

At the last TC meeting [1] we discussed this topic and the various options
that were presented, here's a quick recap:

Options that will be removed, the patches for these options will be
abandoned:
  - Red (option 6), it had the least support
  - Hard black (option 1) in favor of soft black (option 2)
  - Hard white (option 3) in favor of soft white (option 4)

Remaining Options:
  - Soft black (option 2): default option, had no negative feedback,
represents the current status quo
  - Soft white (option 4): had some positive feedback, folks liked it's
simple solution
  - Grey (option 5): had the most positive feedback, but also the least
amount of detail

We'll continue to iterate on the remaining three options.

 - steve

[1]
http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-12-06-20.02.log.txt


On Mon, Nov 28, 2016 at 1:33 PM, Doug Hellmann 
wrote:

> 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.
>
> Some teams for projects that use drivers may not want to manage
> some or all of the drivers that can be consumed by their project
> because they have little insight into testing or debugging the code,
> or do not have the resources needed to manage centrally a large
> number of separate drivers. Vendors are of course free to produce
> drivers to integrate with OpenStack completely outside of the
> community, but because we value having the drivers as well as the
> more general support of vendor companies, we want to encourage a
> higher level of engagement by welcoming vendor-specific teams to
> be a part of our community governance.
>
> Our Requirements for New Projects list [0] includes a statement
> about establishing a "level and open collaboration playing field"
>
>   The project shall provide a level and open collaboration playing
>   field for all contributors. The project shall not benefit a single
>   vendor, or a single vendors product offerings; nor advantage
>   contributors from a single vendor organization due to access to
>   source code, hardware, resources or other proprietary technology
>   available only to those contributors.
>
> This requirement makes it difficult to support having teams focused
> on producing a deliverable that primarily benefits a single vendor.
> So, we have some tension between wanting to collaborate and have a
> level playing field, while wanting to control the amount of driver
> code that projects have to manage.
>
> I'm raising this as an issue because it's not just a hypothetical
> problem. The Cisco networking driver team, having been removed from
> the Neutron stadium, is asking for status as a separate official
> team [1]. I would very much like to find a way to say "yes, welcome
> (back)!"
>
> To that end, I've been working with fungi and ttx to identify all
> of our options. We've come up with a "spectrum", which I will try
> to summarize here but please read the associated governance patches
> for the full details. (Please note that although we've split up the
> work of writing the patches, each author may not necessarily support
> all of the patches he has submitted.)
>
> 1. A resolution reaffirming the "level playing field" requirement,
>and acknowledging that it effectively precludes official status
>for teams which only develop drivers for proprietary systems
>(hard black) [2]
>
>This would have the immediate effect of denying the Cisco team's
>request, as well as precluding future requests from similar teams.
>
> 2. A resolution reaffirming the "level playing field" requirement,
>and acknowledging that it does not necessarily preclude official
>status for teams which only develop drivers for proprietary
>systems (soft black) [3]
>
>This would allow driver-specific teams for systems as long as
>those drivers can be developed without access to proprietary
>information. The TC would have to consider how this applies to
>each team's request as it is evaluated.
>
> 3. A resolution and policy change removing the "level playing field"
>requirement (hard white) [4]
>
>This would completely remove the problematic wording from the
>governance documents (eliminate the restriction on benefiting a
>single company and consider access to specific information for
>some contributors to not be a problem).
>
> 4. A resolution and policy change loosening the "level playing field"
>requirement (soft white) [5]
>
>This would add an exception to the existing wording in the
>governance documents to exempt teams working only on drivers.
>They would still be subject to all of our other policies, unless
>similar exceptions are included.
>
> 5. Consider driver teams to be a completely different animal, 

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Thierry Carrez]

Armando M. wrote:
> 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.

+1

With our team-centric view of community, I don't think it's reasonable
to ask a project team to vouch for code they are not comfortable with
(whatever the reason). At the same time I think we need to find a way to
consider vendor driver development part of OpenStack, without
compromising on our open collaboration principles.

So I think the right trade-off is to recognize that driver teams are
separate beasts, with a narrow scope (implementing an interface designed
by another OpenStack project) and relaxed open collaboration rules...

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Armando M.]

On 30 November 2016 at 02:23, Kevin Benton  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
> 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.
>

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

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Armando M.]

On 29 November 2016 at 10:08, Doug Hellmann  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.
>

I replied to Zane's initial email. I hope that provides some insight as to
why we went down the path we did.

Thanks,
Armando


>
> Doug
>
> >
> > cheers,
> > Zane.
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Armando M.]

On 29 November 2016 at 09:36, Zane Bitter  wrote:

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

In a nutshell: scalability. The list became huge, the core team was made in
charge of dealing with releases requests, backport requests, infra,
governance and doc changes etc. Any of those changes required a neutron
liasion vouching for them. This became untenable, distracting and defeating
the whole point of breaking down the monolithic codebase we were trying to
move away from. I (the PTL since Mitaka) personally felt that we needed to
empower the individual efforts to be in charge or their own destiny and at
the same time making sure that the neutron project as described by the
governance repo was cohesive and made sense to the eye of someone looking
at the project list.

If the eviction or exclusion of a driver caused a project and its
contributors lose their ATC status, access to horizontal teams services
(e.g. representation on docs.o.o, release.o.o), etc, I always thought that
was wrong; that should have not happened, and I hope this effort led by
Doug can fix that.

The neutron team cares about drivers, and I personally believe that are
very important to the success of the OpenStack community. That's why we
enabled the innovation by breaking them out and keeping/augmenting the
extension points provided by the core platform so that they are not stifled
by the chokepoint that the core team may represent. At the same time, I
care about quality and consistency, and I want to be proudly standing
behind the stuff I am involved in, and as such I don't want to be
erroneously associated with initiatives I (and the core team) cannot ever
have the bandwidth to deal with.


> a) Neutron to start agreeing with you; or
> b) The TC to tell Neutron to agree with you; or
> c) To do an end run around Neutron by adding it as a separate project
>
> 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.
>
> 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.
>
> cheers,
> Zane.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Andreas Jaeger]

On 11/30/2016 06:54 PM, Jeremy Stanley wrote:
> On 2016-11-30 09:12:18 -0600 (-0600), Anne Gentle wrote:
>> On Tue, Nov 29, 2016 at 2:53 PM, Jeremy Stanley  wrote:
> [...]
>>> Perhaps they wanted to publish documentation to the
>>> docs.openstack.org site? That's traditionally only been allowed by
>>> the Docs team for official project deliverables.
>>
>> This is a false statement for driver docs. We have had a proprietary driver
>> docs policy [1] in place since 2015, which we collaborated on with driver
>> maintainers, wrote it down, and communicated broadly.
> [...]
> 
> Excellent--thanks! I was blissfully ignorant that you already had
> driver-specific exceptions to that policy.

Let me clarify: Anne speaks about a page in the Configuration Reference
- and this is available for all 3rd party drivers.

docs.o.o/developer/REPO is still for official projects only - a very old
policy that could be reevaluated by the docs team,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Jeremy Stanley]

On 2016-11-30 09:12:18 -0600 (-0600), Anne Gentle wrote:
> On Tue, Nov 29, 2016 at 2:53 PM, Jeremy Stanley  wrote:
[...]
> > Perhaps they wanted to publish documentation to the
> > docs.openstack.org site? That's traditionally only been allowed by
> > the Docs team for official project deliverables.
> 
> This is a false statement for driver docs. We have had a proprietary driver
> docs policy [1] in place since 2015, which we collaborated on with driver
> maintainers, wrote it down, and communicated broadly.
[...]

Excellent--thanks! I was blissfully ignorant that you already had
driver-specific exceptions to that policy.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Alexandra Settle]

To add to that, I am currently in the process of adding the driver docs policy 
guidelines to the Contributor Guide: https://review.openstack.org/#/c/404785/

From: Anne Gentle <annegen...@justwriteclick.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, November 30, 2016 at 3:12 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific 
Drivers



On Tue, Nov 29, 2016 at 2:53 PM, Jeremy Stanley 
<fu...@yuggoth.org<mailto:fu...@yuggoth.org>> wrote:
On 2016-11-29 20:19:13 + (+), gordon chung wrote:
[...]
> i don't recall why they were moved to be officially under the Telemetry
> umbrella[3] but i remember they weren't allowed to do something if they
> weren't part of an 'official' project. if i could remember what it was
> this paragraph would be a lot more useful.
[...]

Perhaps they wanted to publish documentation to the
docs.openstack.org<http://docs.openstack.org> site? That's traditionally only 
been allowed by
the Docs team for official project deliverables.

This is a false statement for driver docs. We have had a proprietary driver 
docs policy [1] in place since 2015, which we collaborated on with driver 
maintainers, wrote it down, and communicated broadly.

The summary is "If a vendor wants full documentation in the Configuration 
Reference, they have to add to the wiki page a contact editor that will take 
care of the vendor driver documentation. The Documentation team will assign 
bugs to the contact person, include the contact person in reviews for the 
vendor driver, and expects timely responses."

The way I see it, soft white, understanding that "level playing field" is not 
exactly the end-goal for OpenStack but that great, tested and functional 
features are, is a compelling way forward. We need accountability, and I do 
think drivers are important and teams should find ways to enable that work in 
meaningful ways while also not overwhelming the common. Believe me the docs 
team has lived this and empathizes with the concerns.

Anne

1. 
https://specs.openstack.org/openstack/docs-specs/specs/kilo/move-driver-docs.html


--
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Anne Gentle
www.justwriteclick.com<http://www.justwriteclick.com>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Anne Gentle]

On Tue, Nov 29, 2016 at 2:53 PM, Jeremy Stanley  wrote:

> On 2016-11-29 20:19:13 + (+), gordon chung wrote:
> [...]
> > i don't recall why they were moved to be officially under the Telemetry
> > umbrella[3] but i remember they weren't allowed to do something if they
> > weren't part of an 'official' project. if i could remember what it was
> > this paragraph would be a lot more useful.
> [...]
>
> Perhaps they wanted to publish documentation to the
> docs.openstack.org site? That's traditionally only been allowed by
> the Docs team for official project deliverables.
>

This is a false statement for driver docs. We have had a proprietary driver
docs policy [1] in place since 2015, which we collaborated on with driver
maintainers, wrote it down, and communicated broadly.

The summary is "If a vendor wants full documentation in the Configuration
Reference, they have to add to the wiki page a contact editor that will
take care of the vendor driver documentation. The Documentation team will
assign bugs to the contact person, include the contact person in reviews
for the vendor driver, and expects timely responses."

The way I see it, soft white, understanding that "level playing field" is
not exactly the end-goal for OpenStack but that great, tested and
functional features are, is a compelling way forward. We need
accountability, and I do think drivers are important and teams should find
ways to enable that work in meaningful ways while also not overwhelming the
common. Believe me the docs team has lived this and empathizes with the
concerns.

Anne

1. https://specs.openstack.org/openstack/docs-specs/
specs/kilo/move-driver-docs.html



> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>

-- 
Anne Gentle
www.justwriteclick.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Kevin Benton]

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

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Clint Byrum]

Excerpts from Jeremy Stanley's message of 2016-11-29 21:52:35 +:
> On 2016-11-29 13:40:56 -0800 (-0800), Clint Byrum wrote:
> > Excerpts from Jeremy Stanley's message of 2016-11-29 21:10:35 +:
> [...]
> > > I also feel very strongly that those alone would be terrible reasons
> > > to consider becoming an official project team under the governance
> > > of the OpenStack Technical Committee. Our project governance is not
> > > intended as a means of marketing and advertising products, and I'm
> > > going to do my best to make sure that it's extremely ineffective at
> > > that for any companies who try to (ab)use it to those ends.
> > 
> > This struck me as overly aggressive. Open Source is a social model, and
> > if a commercial entity would like to participate in that social model
> > in good faith, I think that's beneficial to everyone else. Throwing
> > up a "not for commercial use" barrier to their participation will just
> > discourage them and others from investing more.
> 
> Thanks, it was not at all my intent to be aggressive towards Sam and
> I neglected to state that I agree the first part of his reply (which
> I had trimmed) was a fine set of reasons to seek becoming an
> official OpenStack project team. So sorry, Sam (and everyone else)!
> 
> It was however my intent to be aggressive in defending our use of
> project governance for actually governing the direction of
> OpenStack, and I don't want to see it perverted into a product
> marketing platform. We need better ways to help vendors advertise
> their driver support without bringing the TC into the picture as a
> deciding body. It's more work for the TC, and it gets in the way of
> what everyone actually wants to accomplish.

Thanks for clarifying Jeremy. :)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Jeremy Stanley]

On 2016-11-29 13:40:56 -0800 (-0800), Clint Byrum wrote:
> Excerpts from Jeremy Stanley's message of 2016-11-29 21:10:35 +:
[...]
> > I also feel very strongly that those alone would be terrible reasons
> > to consider becoming an official project team under the governance
> > of the OpenStack Technical Committee. Our project governance is not
> > intended as a means of marketing and advertising products, and I'm
> > going to do my best to make sure that it's extremely ineffective at
> > that for any companies who try to (ab)use it to those ends.
> 
> This struck me as overly aggressive. Open Source is a social model, and
> if a commercial entity would like to participate in that social model
> in good faith, I think that's beneficial to everyone else. Throwing
> up a "not for commercial use" barrier to their participation will just
> discourage them and others from investing more.

Thanks, it was not at all my intent to be aggressive towards Sam and
I neglected to state that I agree the first part of his reply (which
I had trimmed) was a fine set of reasons to seek becoming an
official OpenStack project team. So sorry, Sam (and everyone else)!

It was however my intent to be aggressive in defending our use of
project governance for actually governing the direction of
OpenStack, and I don't want to see it perverted into a product
marketing platform. We need better ways to help vendors advertise
their driver support without bringing the TC into the picture as a
deciding body. It's more work for the TC, and it gets in the way of
what everyone actually wants to accomplish.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Clint Byrum]

Excerpts from Jeremy Stanley's message of 2016-11-29 21:10:35 +:
> On 2016-11-29 21:00:06 + (+), Sam Betts (sambetts) wrote:
> [...]
> > Additionally, being “official” indicates a level of maturity which
> > benefits us as a project by improving the public perception of our
> > drivers, and also indicates to OpenStack users that OpenStack
> > itself is mature and has support for existing technologies and
> > physical equipment out of the box. We want to make the Cisco
> > drivers visible/discoverable so that operators evaluating
> > OpenStack for their use cases will easily be able to know if a
> > driver for their equipment exists without digging around in git
> > repos.
> > 
> > In our current state (not an official project or under an official
> > project) we can’t publish our existence, releases or docs to any
> > official location on *.openstack.org which makes it difficult for
> > those new to OpenStack to know we exist, or find any information
> > on how to deploy/use Cisco equipment with OpenStack.
> 
> [Please trim quoted material and avoid top-posting.]
> 
> Would better visibility for
> https://www.openstack.org/marketplace/drivers/ (perhaps with a more
> navigable UI and updated for the latest release) address those
> concerns? I absolutely want service teams to have a mechanism by
> which they can list known working/supported drivers in an
> official-looking place so vendors can point their customers at that.
> 
> I also feel very strongly that those alone would be terrible reasons
> to consider becoming an official project team under the governance
> of the OpenStack Technical Committee. Our project governance is not
> intended as a means of marketing and advertising products, and I'm
> going to do my best to make sure that it's extremely ineffective at
> that for any companies who try to (ab)use it to those ends.

This struck me as overly aggressive. Open Source is a social model, and
if a commercial entity would like to participate in that social model
in good faith, I think that's beneficial to everyone else. Throwing
up a "not for commercial use" barrier to their participation will just
discourage them and others from investing more.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Doug Hellmann]

Excerpts from Sam Betts (sambetts)'s message of 2016-11-29 21:00:06 +:
> There are a couple of reasons we want to become an official OpenStack project.
> 
> From a project perspective, we want to be recognized that the project isn’t 
> just a “public source” repo for Cisco’s drivers but is a community driven 
> open source project for supporting Cisco hardware/software and we want to 
> encourage community members that are using Cisco equipment to participate 
> with us contributing to and helping improve the drivers.

Thanks, Sam. This is the spirit I think we should be encouraging for all
projects.

Doug

> 
> Additionally, being “official” indicates a level of maturity which benefits 
> us as a project by improving the public perception of our drivers, and also 
> indicates to OpenStack users that OpenStack itself is mature and has support 
> for existing technologies and physical equipment out of the box. We want to 
> make the Cisco drivers visible/discoverable so that operators evaluating 
> OpenStack for their use cases will easily be able to know if a driver for 
> their equipment exists without digging around in git repos. 
> 
> In our current state (not an official project or under an official project) 
> we can’t publish our existence, releases or docs to any official location on 
> *.openstack.org which makes it difficult for those new to OpenStack to know 
> we exist, or find any information on how to deploy/use Cisco equipment with 
> OpenStack.
> 
> Sam

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[gordon chung]

On 29/11/16 03:53 PM, Jeremy Stanley wrote:
> Perhaps they wanted to publish documentation to the
> docs.openstack.org site? That's traditionally only been allowed by
> the Docs team for official project deliverables.

that's probably it, i just couldn't find their docs.

from our experience, we don't really have any issues with their driver 
being in a separate project under our umbrella. probably biggest concern 
is that we don't actively track the powervm project so we honestly don't 
know know its current status (or at least i don't). we currently just 
say 'do your own research' regarding anything managed by a separate team 
which may or may not be the best answer.

cheers,
-- 
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Jeremy Stanley]

On 2016-11-29 21:00:06 + (+), Sam Betts (sambetts) wrote:
[...]
> Additionally, being “official” indicates a level of maturity which
> benefits us as a project by improving the public perception of our
> drivers, and also indicates to OpenStack users that OpenStack
> itself is mature and has support for existing technologies and
> physical equipment out of the box. We want to make the Cisco
> drivers visible/discoverable so that operators evaluating
> OpenStack for their use cases will easily be able to know if a
> driver for their equipment exists without digging around in git
> repos.
> 
> In our current state (not an official project or under an official
> project) we can’t publish our existence, releases or docs to any
> official location on *.openstack.org which makes it difficult for
> those new to OpenStack to know we exist, or find any information
> on how to deploy/use Cisco equipment with OpenStack.

[Please trim quoted material and avoid top-posting.]

Would better visibility for
https://www.openstack.org/marketplace/drivers/ (perhaps with a more
navigable UI and updated for the latest release) address those
concerns? I absolutely want service teams to have a mechanism by
which they can list known working/supported drivers in an
official-looking place so vendors can point their customers at that.

I also feel very strongly that those alone would be terrible reasons
to consider becoming an official project team under the governance
of the OpenStack Technical Committee. Our project governance is not
intended as a means of marketing and advertising products, and I'm
going to do my best to make sure that it's extremely ineffective at
that for any companies who try to (ab)use it to those ends.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Sam Betts (sambetts)]

There are a couple of reasons we want to become an official OpenStack project.

From a project perspective, we want to be recognized that the project isn’t 
just a “public source” repo for Cisco’s drivers but is a community driven open 
source project for supporting Cisco hardware/software and we want to encourage 
community members that are using Cisco equipment to participate with us 
contributing to and helping improve the drivers.

Additionally, being “official” indicates a level of maturity which benefits us 
as a project by improving the public perception of our drivers, and also 
indicates to OpenStack users that OpenStack itself is mature and has support 
for existing technologies and physical equipment out of the box. We want to 
make the Cisco drivers visible/discoverable so that operators evaluating 
OpenStack for their use cases will easily be able to know if a driver for their 
equipment exists without digging around in git repos. 

In our current state (not an official project or under an official project) we 
can’t publish our existence, releases or docs to any official location on 
*.openstack.org which makes it difficult for those new to OpenStack to know we 
exist, or find any information on how to deploy/use Cisco equipment with 
OpenStack.

Sam

On 28/11/2016, 19:14, "Jay Pipes"  wrote:

On 11/28/2016 01:33 PM, Doug Hellmann wrote:
> I'm raising this as an issue because it's not just a hypothetical
> problem. The Cisco networking driver team, having been removed from
> the Neutron stadium, is asking for status as a separate official
> team [1]. I would very much like to find a way to say "yes, welcome
> (back)!"

These questions are to the Cisco networking team.

What value do *you* think you derive from being an official OpenStack 
project team?

What value do you believe OpenStack *users* would get from you being an 
official OpenStack project team?

If you are *not* accepted as an official OpenStack project team, what 
actual impact would that have on OpenStack users, if any?

Thanks in advance for your answers.

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Jeremy Stanley]

On 2016-11-29 20:19:13 + (+), gordon chung wrote:
[...]
> i don't recall why they were moved to be officially under the Telemetry
> umbrella[3] but i remember they weren't allowed to do something if they
> weren't part of an 'official' project. if i could remember what it was
> this paragraph would be a lot more useful.
[...]

Perhaps they wanted to publish documentation to the
docs.openstack.org site? That's traditionally only been allowed by
the Docs team for official project deliverables.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[gordon chung]

On 29/11/16 01:24 PM, Doug Hellmann wrote:
> If we start by assuming that contributors may end up getting more
> value from seeming to be a part of the community than the community
> will get from their participation, and that we have to guard against
> that because it somehow diminishes us, it seems like we would be
> rejecting the notion of having an open community in the first place.
>
> Not every useful contribution is going to come from someone with
> the time to participate 100%, or even 50%, upstream.  Not every
> useful contribution is going to be code changes to the core components
> of a project.
>
> I know that our experience with third-party CI for some vendors has
> been poor in the past. I don't believe the answer is to tell all
> vendors to go away.
>
> As long as we clearly communicate to users how drivers are tested,
> and who owns failures, collaborating with vendors who only have the
> resources (or interest) to contribute a driver shouldn't be considered
> a burden. If they want more influence over the direction of a
> project, they need to participate at a level to make it possible for
> them to have that influence. In the mean time, I see no harm in making
> it possible for them to participate at the level of commitment they're
> ready to make.

i like this summary.

we had this issue in Ceilometer with our compute pollsters. we wanted to 
support polling from all the different hypervisors but obviously the 
members of the core team were not necessarily hypervisor experts. we 
were in the strange scenario where cores were reviewing stuff that we 
didn't necessarily understand. it also didn't really make sense to make 
someone a ceilometer core if all they wanted was a quick patch to 
capture a metric in one of the hypervisors.

with ceilometer-powervm[1], the IBM team wrote their own driver which 
matched our api requirements but they managed everything themselves in 
another project with the appropriate testing. we just added their 
project as an externally-managed project in our wiki.[2]

i don't recall why they were moved to be officially under the Telemetry 
umbrella[3] but i remember they weren't allowed to do something if they 
weren't part of an 'official' project. if i could remember what it was 
this paragraph would be a lot more useful.

[1] https://github.com/openstack/ceilometer-powervm
[2] https://wiki.openstack.org/wiki/Telemetry#Externally_Managed
[3] https://review.openstack.org/#/c/245894/

cheers,

-- 
gord

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Doug Hellmann]

Excerpts from Chris Friesen's message of 2016-11-29 11:55:30 -0600:
> On 11/29/2016 10:55 AM, Doug Hellmann wrote:
> 
> > I agree that clearly documenting who supports each driver, and how
> > tightly integrated that team is with the core team will be important.
> > That will be the case no matter what solution we pick (even saying
> > that drivers aren't official isn't going to avoid questions about
> > how well supported a driver is). I left the details of how to do
> > that up to the individual teams, since I know some are already
> > working on it.
> 
> For what it's worth, in the linux kernel there is a "MAINTAINERS" file which 
> documents who's in charge of each driver, any appropriate mailing lists, 
> source 
> code repositories, etc. That way people with questions about a driver can 
> communicate with the people involved with developing that driver.  The 
> overall 
> kernel maintainers make few statements about how well-supported any given 
> driver is.
> 
> Perhaps something like that could be used as a model.
> 
> Chris
> 

That does sound like a good starting point.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Doug Hellmann]

Excerpts from Anita Kuno's message of 2016-11-29 12:37:21 -0500:
> On 2016-11-29 11:27 AM, Jeremy Stanley wrote:
> > I think we also need to look harder at the reasons for driver-only
> > developer teams seeking official status. If it's because they want
> > to be part of the community and help collaborate with the rest of
> > us, then as long as they can do that consistent with our overall
> > goals and ideals I think that's great and we should welcome them as
> > one of us. If the reason is because they feel it raises the profile
> > of their products within the OpenStack ecosystem or conveys an
> > implication of better OpenStack support on their platforms, then we
> > should work harder as a community to dispel that notion (even if it
> > means we need to actively sabotage the "tent" as a marketing
> > platform) and find other places for companies to advertise the level
> > of OpenStack support their customers should expect.
> 
> I think Jeremy raises a very important point here. What is the 
> motivation on the part of the driver-only teams?
> 
> I personally assumed far too much collaborative intent when I got 
> involved with supporting the path to third party testing for drivers. My 
> eyes have since been opened. While there are a few driver maintainers 
> that are motivated to be collaborative and help others (thank you so 
> much) they are far from the norm.
> 
> I've taken some time away from keyboard to navel gaze a bit and been 
> quite enjoying it. I've been able to think about some of the material 
> offered to us during the leadership training in June, particularly 
> thinking about groups that are successful in creating an environment of 
> collaboration. I found that one of the most important aspects of groups 
> that do create and maintain a collaborate atmosphere for all concerned 
> is the ability to ensure that all concerned are motivated to create a 
> collaborative environment. Businesses offered as case studies in the 
> literature provided by Zingermans, create a reciprocally beneficial 
> collaborative environment through rigorous filtering during interview 
> and selection processes as well as a commitment to help people move 
> along should it be evident that they are not motivated by collaborative 
> intent. OpenStack can't apply the process but it can align with the 
> spirit of the intent, should OpenStack continue to want to create a 
> collaborative environment for all concerned.
> 
> Some may feel excluded and that is their choice, as long as there is 
> always a door way in for those that make the choice of having their 
> actions motivated by collaboration for the benefit of all concerned.
> 
> Thank you,
> Anita.
> 

If we start by assuming that contributors may end up getting more
value from seeming to be a part of the community than the community
will get from their participation, and that we have to guard against
that because it somehow diminishes us, it seems like we would be
rejecting the notion of having an open community in the first place.

Not every useful contribution is going to come from someone with
the time to participate 100%, or even 50%, upstream.  Not every
useful contribution is going to be code changes to the core components
of a project.

I know that our experience with third-party CI for some vendors has
been poor in the past. I don't believe the answer is to tell all
vendors to go away.

As long as we clearly communicate to users how drivers are tested,
and who owns failures, collaborating with vendors who only have the
resources (or interest) to contribute a driver shouldn't be considered
a burden. If they want more influence over the direction of a
project, they need to participate at a level to make it possible for
them to have that influence. In the mean time, I see no harm in making
it possible for them to participate at the level of commitment they're
ready to make.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Doug Hellmann]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Chris Friesen]

On 11/29/2016 10:55 AM, Doug Hellmann wrote:


I agree that clearly documenting who supports each driver, and how
tightly integrated that team is with the core team will be important.
That will be the case no matter what solution we pick (even saying
that drivers aren't official isn't going to avoid questions about
how well supported a driver is). I left the details of how to do
that up to the individual teams, since I know some are already
working on it.


For what it's worth, in the linux kernel there is a "MAINTAINERS" file which 
documents who's in charge of each driver, any appropriate mailing lists, source 
code repositories, etc. That way people with questions about a driver can 
communicate with the people involved with developing that driver.  The overall 
kernel maintainers make few statements about how well-supported any given driver is.


Perhaps something like that could be used as a model.

Chris


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Anita Kuno]

On 2016-11-29 11:27 AM, Jeremy Stanley wrote:

I think we also need to look harder at the reasons for driver-only
developer teams seeking official status. If it's because they want
to be part of the community and help collaborate with the rest of
us, then as long as they can do that consistent with our overall
goals and ideals I think that's great and we should welcome them as
one of us. If the reason is because they feel it raises the profile
of their products within the OpenStack ecosystem or conveys an
implication of better OpenStack support on their platforms, then we
should work harder as a community to dispel that notion (even if it
means we need to actively sabotage the "tent" as a marketing
platform) and find other places for companies to advertise the level
of OpenStack support their customers should expect.


I think Jeremy raises a very important point here. What is the 
motivation on the part of the driver-only teams?


I personally assumed far too much collaborative intent when I got 
involved with supporting the path to third party testing for drivers. My 
eyes have since been opened. While there are a few driver maintainers 
that are motivated to be collaborative and help others (thank you so 
much) they are far from the norm.


I've taken some time away from keyboard to navel gaze a bit and been 
quite enjoying it. I've been able to think about some of the material 
offered to us during the leadership training in June, particularly 
thinking about groups that are successful in creating an environment of 
collaboration. I found that one of the most important aspects of groups 
that do create and maintain a collaborate atmosphere for all concerned 
is the ability to ensure that all concerned are motivated to create a 
collaborative environment. Businesses offered as case studies in the 
literature provided by Zingermans, create a reciprocally beneficial 
collaborative environment through rigorous filtering during interview 
and selection processes as well as a commitment to help people move 
along should it be evident that they are not motivated by collaborative 
intent. OpenStack can't apply the process but it can align with the 
spirit of the intent, should OpenStack continue to want to create a 
collaborative environment for all concerned.


Some may feel excluded and that is their choice, as long as there is 
always a door way in for those that make the choice of having their 
actions motivated by collaboration for the benefit of all concerned.


Thank you,
Anita.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Zane Bitter]

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
c) To do an end run around Neutron by adding it as a separate project

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.


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.


cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Doug Hellmann]

Excerpts from Flavio Percoco's message of 2016-11-29 17:19:15 +0100:
> On 28/11/16 13:33 -0500, Doug Hellmann wrote:
> >5. Consider driver teams to be a completely different animal, defined
> >   in drivers.yaml instead of projects.yaml (grey option) [6]
> >
> >   This establishes drivers as second-order objects that are necessary
> >   for the success of the main projects, and for which requirements
> >   can be loosened. It would establish a new category of team without
> >   the level playing-field requirement and some of the other team
> >   requirements that seem not to apply to driver teams because they
> >   are essentially a public facet of a single vendor.
> >
> >6. A resolution requiring projects that consume drivers to host all
> >   proposed drivers. (red option) [7]
> >
> >   This would require teams with projects providing driver interfaces
> >   to also host, in some form, drivers from vendors that ask for
> >   hosting. The drivers would not need to be in the main project
> >   repo, but would need to be in a repository "owned" by the project
> >   team. Project teams would not be considered responsible for the
> >   quality of the resulting drivers.  Contributors to the driver
> >   repos would be considered part of the electorate for team PTL.
> 
> 
> These two are my preferred options so far. They both recognize drivers and 
> allow
> for this drivers to officially exist in the community. I like the idea of 
> having
> the drivers and services under the same team. I'd prefer them to have one PTL
> and for there to be more interactions between driver owners and the rest of 
> the
> service team.
> 
> One thing that worries me about #6, which #5 solves, is that it doesn't 
> clearly
> identify drivers. We've had problems in the past communicating the status of
> projects to other members, operators and end users. I'm worried that the 
> quality
> and stability of some of these drivers would affect a project's "reputation" 
> (so
> to speak). Proposal #6 says that project teams must host these drivers but 
> they
> are not really accountable for the drivers if they don't live in-tree (note 
> this
> could happen even for drivers that are in-tree).
> 
> The above is all to say that I'd feel more comfortable with proposal #6 if it
> would provide a way to communicate that these repos are drivers, that they are
> maintained by a subset of the bigger team, etc. This is something #5 solves by
> clearly saying that some driver teams are different. This separation is not 
> only
> useful from a community perspective but also for managing these 
> projects/repos.
> It allows for setting a new set of rules instead of adding exceptions to the
> existing ones.
> 
> What I don't like about #5 is that increases the complexity of the process for
> adding new projects and it may make communication between these teams more
> difficult. It will force the creation of tiny teams w/ all the things required
> for teams to exist (PTL elections, ATC management, extra ATC, and what not).
> 
> At this point I think I'm leaning more towards #5 because it acknowledges 
> these
> drivers are useful but they are essentially managed by a different team, which
> is something that #6 doesn't do.
> 
> I'll try to come up with some proposals to have #6 communicate this, unless it
> was left out on purpose.

I agree that clearly documenting who supports each driver, and how
tightly integrated that team is with the core team will be important.
That will be the case no matter what solution we pick (even saying
that drivers aren't official isn't going to avoid questions about
how well supported a driver is). I left the details of how to do
that up to the individual teams, since I know some are already
working on it.

Doug

> 
> Thank you all for working on this,
> Flavio
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Jeremy Stanley]

On 2016-11-28 13:33:56 -0500 (-0500), Doug Hellmann wrote:
[...]
> 1. A resolution reaffirming the "level playing field" requirement,
>and acknowledging that it effectively precludes official status
>for teams which only develop drivers for proprietary systems
>(hard black) [2]
[...]
> 2. A resolution reaffirming the "level playing field" requirement,
>and acknowledging that it does not necessarily preclude official
>status for teams which only develop drivers for proprietary
>systems (soft black) [3]
[...]
> 3. A resolution and policy change removing the "level playing field"
>requirement (hard white) [4]
[...]
> 4. A resolution and policy change loosening the "level playing field"
>requirement (soft white) [5]
[...]
> [2] https://review.openstack.org/403834 - Proprietary driver dev is unlevel
> [3] https://review.openstack.org/403836 - Driver development can be level
> [4] https://review.openstack.org/403838 - Stop requiring a level playing field
> [5] https://review.openstack.org/403839 - Level playing fields, except drivers
[...]

I proposed these because I have a strong preference not to bury the
problem in additional bureaucracy. Either we determine that we want
to recognize the developers writing drivers as an official part of
our community and need to reinterpret/adjust our policies because
they're in conflict with our intent, or we decide that the intent of
our policy necessarily precludes official recognition for driver
teams. Without addressing this issue at its source, we're sort of
avoiding addressing it at all.

I'm not really a fan of the more complex solutions proposed, since
they don't seem (to me) to address the fundamental issue. I feel
like the "Big Tent" only remains true to its design if we have one
kind of team in it. As soon as we begin to define second-class teams
that are still in some way "official" we're back to much of the same
conflict and tension which drove us to our current governance model
in the first place.

The scaling concerns from allowing too many "small" teams who only
develop drivers should be dealt with as a separate issue. There are
plenty of other small, single-affiliation developer teams working
within our community and I think whatever solutions we come up with
for scaling limited resources in the tent shouldn't single out
driver development as the cause.

I think we also need to look harder at the reasons for driver-only
developer teams seeking official status. If it's because they want
to be part of the community and help collaborate with the rest of
us, then as long as they can do that consistent with our overall
goals and ideals I think that's great and we should welcome them as
one of us. If the reason is because they feel it raises the profile
of their products within the OpenStack ecosystem or conveys an
implication of better OpenStack support on their platforms, then we
should work harder as a community to dispel that notion (even if it
means we need to actively sabotage the "tent" as a marketing
platform) and find other places for companies to advertise the level
of OpenStack support their customers should expect.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Flavio Percoco]

On 28/11/16 13:33 -0500, Doug Hellmann wrote:

5. Consider driver teams to be a completely different animal, defined
  in drivers.yaml instead of projects.yaml (grey option) [6]

  This establishes drivers as second-order objects that are necessary
  for the success of the main projects, and for which requirements
  can be loosened. It would establish a new category of team without
  the level playing-field requirement and some of the other team
  requirements that seem not to apply to driver teams because they
  are essentially a public facet of a single vendor.

6. A resolution requiring projects that consume drivers to host all
  proposed drivers. (red option) [7]

  This would require teams with projects providing driver interfaces
  to also host, in some form, drivers from vendors that ask for
  hosting. The drivers would not need to be in the main project
  repo, but would need to be in a repository "owned" by the project
  team. Project teams would not be considered responsible for the
  quality of the resulting drivers.  Contributors to the driver
  repos would be considered part of the electorate for team PTL.



These two are my preferred options so far. They both recognize drivers and allow
for this drivers to officially exist in the community. I like the idea of having
the drivers and services under the same team. I'd prefer them to have one PTL
and for there to be more interactions between driver owners and the rest of the
service team.

One thing that worries me about #6, which #5 solves, is that it doesn't clearly
identify drivers. We've had problems in the past communicating the status of
projects to other members, operators and end users. I'm worried that the quality
and stability of some of these drivers would affect a project's "reputation" (so
to speak). Proposal #6 says that project teams must host these drivers but they
are not really accountable for the drivers if they don't live in-tree (note this
could happen even for drivers that are in-tree).

The above is all to say that I'd feel more comfortable with proposal #6 if it
would provide a way to communicate that these repos are drivers, that they are
maintained by a subset of the bigger team, etc. This is something #5 solves by
clearly saying that some driver teams are different. This separation is not only
useful from a community perspective but also for managing these projects/repos.
It allows for setting a new set of rules instead of adding exceptions to the
existing ones.

What I don't like about #5 is that increases the complexity of the process for
adding new projects and it may make communication between these teams more
difficult. It will force the creation of tiny teams w/ all the things required
for teams to exist (PTL elections, ATC management, extra ATC, and what not).

At this point I think I'm leaning more towards #5 because it acknowledges these
drivers are useful but they are essentially managed by a different team, which
is something that #6 doesn't do.

I'll try to come up with some proposals to have #6 communicate this, unless it
was left out on purpose.

Thank you all for working on this,
Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Doug Hellmann]

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

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Chris Friesen]

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


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Doug Hellmann]

I'll rank my preferred solutions, because I don't actually like any of
them.

Excerpts from Doug Hellmann's message of 2016-11-28 13:33:56 -0500:

> 6. A resolution requiring projects that consume drivers to host all
>proposed drivers. (red option) [7]
> 
>This would require teams with projects providing driver interfaces
>to also host, in some form, drivers from vendors that ask for
>hosting. The drivers would not need to be in the main project
>repo, but would need to be in a repository "owned" by the project
>team. Project teams would not be considered responsible for the
>quality of the resulting drivers.  Contributors to the driver
>repos would be considered part of the electorate for team PTL.

Ideally this question wouldn't even need to be discussed because
teams would accept all drivers, in some form, because they recognize
the importance of contribution of drivers to the success of their
project and OpenStack as a whole. The result would be some drivers
in-tree and others in a separate repository, as described in option
6, without the TC requiring teams to accept the code. This would
encourage collaboration and stem the proliferation of extra teams,
which forestalls some of the issues we're anticipating with resources
at the PTG, Summit, etc.

I understand that the actual social interactions within some teams,
and between teams and contributors from vendors, hasn't been ideal,
but I'm still not convinced that the current path is the right
solution. It will not encourage anyone who is not contributing to
the common parts of a project to do so, and it sets the wrong tone
for the necessary future interactions that happen between contributors
discussing code at driver API boundaries.

The proposal Sean has for the Cinder team to allow a "class 2"
driver type that is basically marked as unsupported by the core
team seems like it's a good compromise and something we could do
in all projects to help users understand the support level of all
the drivers they use (with some of the implementation details to
be worked out).

> 3. A resolution and policy change removing the "level playing field"
>requirement (hard white) [4]
> 
>This would completely remove the problematic wording from the
>governance documents (eliminate the restriction on benefiting a
>single company and consider access to specific information for
>some contributors to not be a problem).

If there's no general agreement that teams should host driver
contributions, then I would prefer option 3, which simplifies our
rules instead of adding more. The TC can recognize when a single-vendor
project does not benefit the overall community, and reject it on
those grounds, while allowing driver development teams. We can manage
PTG space and other scarce resources using similar judgment.

> 5. Consider driver teams to be a completely different animal, defined
>in drivers.yaml instead of projects.yaml (grey option) [6]
> 
>This establishes drivers as second-order objects that are necessary
>for the success of the main projects, and for which requirements
>can be loosened. It would establish a new category of team without
>the level playing-field requirement and some of the other team
>requirements that seem not to apply to driver teams because they
>are essentially a public facet of a single vendor.

If we feel the need to codify the differences between two types of
teams, then I'll help refine some version of option 5 to do that.

Doug

> [0] http://governance.openstack.org/reference/new-projects-requirements.html 
> - requirements for new projects
> [1] https://review.openstack.org/363709 - Add networking-cisco back into the 
> Big Tent
> [2] https://review.openstack.org/403834 - Proprietary driver dev is unlevel
> [3] https://review.openstack.org/403836 - Driver development can be level
> [4] https://review.openstack.org/403838 - Stop requiring a level playing field
> [5] https://review.openstack.org/403839 - Level playing fields, except drivers
> [6] https://review.openstack.org/403829 - establish a new "driver team" 
> concept
> [7] https://review.openstack.org/403830 - add resolution requiring teams to 
> accept driver contributions
> [8] https://review.openstack.org/403826 - add a resolution allowing teams 
> based on vendor-specific drivers

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Thierry Carrez]

Doug Hellmann wrote:
> [...]
> 5. Consider driver teams to be a completely different animal, defined
>in drivers.yaml instead of projects.yaml (grey option) [6]
> 
>This establishes drivers as second-order objects that are necessary
>for the success of the main projects, and for which requirements
>can be loosened. It would establish a new category of team without
>the level playing-field requirement and some of the other team
>requirements that seem not to apply to driver teams because they
>are essentially a public facet of a single vendor.

My preference goes to this option.

I think it's important to continue to say that all OpenStack projects
are expected to be developed as a fair and open collaboration. This is
the reason why we are here. However, some teams work on implementing
drivers for those projects, using established plug-in points to enable
external software, proprietary solutions or hardware to work with
OpenStack. Those drivers are an integral part of the success of our
openly-developed projects, but by their very nature we can't enforce the
same level playing field over proprietary driver development. As a
community, we need those drivers for the success of our mission.

This option basically says that we welcome those driver teams as a part
of our community, while recognizing that they are a different animal. In
this specific and narrow case (second-order objects that implement a
pluggable extension point defined by an OpenStack project) we accept a
different set of team requirements (removing the level playing field
principle). Tracking those teams and their requirements separately
ensures that this deviation is not affecting the message for the main
projects.

An alternative would be the "soft white" option, but I think that if
those teams have different requirements and very limited scope, it's
simpler to list them separately rather than put them all in the same
file. It avoids diluting the "open collaboration" message we send to the
main projects.

I would also be fine with the the "soft black" option (which is
basically repeating the current situation).

Regards,

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Jay Pipes]

On 11/28/2016 01:33 PM, Doug Hellmann wrote:

I'm raising this as an issue because it's not just a hypothetical
problem. The Cisco networking driver team, having been removed from
the Neutron stadium, is asking for status as a separate official
team [1]. I would very much like to find a way to say "yes, welcome
(back)!"


These questions are to the Cisco networking team.

What value do *you* think you derive from being an official OpenStack 
project team?


What value do you believe OpenStack *users* would get from you being an 
official OpenStack project team?


If you are *not* accepted as an official OpenStack project team, what 
actual impact would that have on OpenStack users, if any?


Thanks in advance for your answers.

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Doug Hellmann]

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.

Some teams for projects that use drivers may not want to manage
some or all of the drivers that can be consumed by their project
because they have little insight into testing or debugging the code,
or do not have the resources needed to manage centrally a large
number of separate drivers. Vendors are of course free to produce
drivers to integrate with OpenStack completely outside of the
community, but because we value having the drivers as well as the
more general support of vendor companies, we want to encourage a
higher level of engagement by welcoming vendor-specific teams to
be a part of our community governance.

Our Requirements for New Projects list [0] includes a statement
about establishing a "level and open collaboration playing field"

  The project shall provide a level and open collaboration playing
  field for all contributors. The project shall not benefit a single
  vendor, or a single vendors product offerings; nor advantage
  contributors from a single vendor organization due to access to
  source code, hardware, resources or other proprietary technology
  available only to those contributors.

This requirement makes it difficult to support having teams focused
on producing a deliverable that primarily benefits a single vendor.
So, we have some tension between wanting to collaborate and have a
level playing field, while wanting to control the amount of driver
code that projects have to manage.

I'm raising this as an issue because it's not just a hypothetical
problem. The Cisco networking driver team, having been removed from
the Neutron stadium, is asking for status as a separate official
team [1]. I would very much like to find a way to say "yes, welcome
(back)!"

To that end, I've been working with fungi and ttx to identify all
of our options. We've come up with a "spectrum", which I will try
to summarize here but please read the associated governance patches
for the full details. (Please note that although we've split up the
work of writing the patches, each author may not necessarily support
all of the patches he has submitted.)

1. A resolution reaffirming the "level playing field" requirement,
   and acknowledging that it effectively precludes official status
   for teams which only develop drivers for proprietary systems
   (hard black) [2]

   This would have the immediate effect of denying the Cisco team's
   request, as well as precluding future requests from similar teams.

2. A resolution reaffirming the "level playing field" requirement,
   and acknowledging that it does not necessarily preclude official
   status for teams which only develop drivers for proprietary
   systems (soft black) [3]

   This would allow driver-specific teams for systems as long as
   those drivers can be developed without access to proprietary
   information. The TC would have to consider how this applies to
   each team's request as it is evaluated.

3. A resolution and policy change removing the "level playing field"
   requirement (hard white) [4]

   This would completely remove the problematic wording from the
   governance documents (eliminate the restriction on benefiting a
   single company and consider access to specific information for
   some contributors to not be a problem).

4. A resolution and policy change loosening the "level playing field"
   requirement (soft white) [5]

   This would add an exception to the existing wording in the
   governance documents to exempt teams working only on drivers.
   They would still be subject to all of our other policies, unless
   similar exceptions are included.

5. Consider driver teams to be a completely different animal, defined
   in drivers.yaml instead of projects.yaml (grey option) [6]

   This establishes drivers as second-order objects that are necessary
   for the success of the main projects, and for which requirements
   can be loosened. It would establish a new category of team without
   the level playing-field requirement and some of the other team
   requirements that seem not to apply to driver teams because they
   are essentially a public facet of a single vendor.

6. A resolution requiring projects that consume drivers to host all
   proposed drivers. (red option) [7]

   This would require teams with projects providing driver interfaces
   to also host, in some form, drivers from vendors that ask for
   hosting. The drivers would not need to be in the main project
   repo, but would need to be in a repository "owned" by the project
   team. Project teams would not be considered responsible for the
   quality of the resulting drivers.  Contributors to the driver
   repos would be considered part of the electorate for team PTL.

7.