Open Stack

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 <doug at doughellmann.com>
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, 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. A resolution proposing to allow driver-teams, without specifying
>    any implementation details. [8]
>
>    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
>    approach.
>
> 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.
>
> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161209/6a64a185/attachment.html>