[openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers
s.martinelli at gmail.com
Fri Dec 9 20:01:52 UTC 2016
At the last TC meeting  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
- 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)
- 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
- 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.
On Mon, Nov 28, 2016 at 1:33 PM, Doug Hellmann <doug at doughellmann.com>
> 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  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 . I would very much like to find a way to say "yes, welcome
> 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) 
> 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) 
> 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) 
> 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) 
> 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) 
> 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) 
> 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. A resolution proposing to allow driver-teams, without specifying
> any implementation details. 
> This may go along with option 2, 3, 4, or 5. It may also be used
> as the basis for an alternative proposal if we have missed an
> We also need to consider while making the situation better that we
> not have a huge proliferation of these new teams. For example, some
> resources given to teams are finite (CI resources, space at PTGs
> and Summits, foundation staff support, cross-project team support).
> We also don't want to encourage driver authors to move their code
> out of projects that are willing to host them just because they
> can. Therefore, it is likely that even if we do allow driver teams
> in some form (options 2, 3, 4, and 5), they will have fewer rights
> than teams building abstraction layers that use the drivers.
> Again, these options are presented to give a more complete picture
> and not because we necessarily support all of them (obviously, some
> of them are clearly in conflict). I'll post my personal opinions
> in a follow up message to avoid editorializing here.
>  http://governance.openstack.org/reference/new-projects-
> requirements.html - requirements for new projects
>  https://review.openstack.org/363709 - Add networking-cisco back into
> the Big Tent
>  https://review.openstack.org/403834 - Proprietary driver dev is
>  https://review.openstack.org/403836 - Driver development can be level
>  https://review.openstack.org/403838 - Stop requiring a level playing
>  https://review.openstack.org/403839 - Level playing fields, except
>  https://review.openstack.org/403829 - establish a new "driver team"
>  https://review.openstack.org/403830 - add resolution requiring teams
> to accept driver contributions
>  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-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev