openinfra/interop
Code Issues Proposed changes

Major update of Interop WG process rules.

Browse Source 
Created new named TrademarkProgram.rst.
Kept old doc CoreDefintion.rst that is replaced by
TrademarkProgram.rst.
Core Defintion is no longer defined by TC.
Removed old reference to Havana and Grizzly release.
Updated meeting info.
Add coverage for Add-on programs.
Added coverage to drivers and vendor plugins, cleaned up language
for laternative implementation.
Added that board delegated its approval of guidelines
to the Approval Committee.
Any process changes need to get approved by the Board.

Change-Id: Ie439e1c8ff015621bf8936994173c095f0d08970
This commit is contained in:
ArkadyKanevsky 2021-04-02 21:36:07 -05:00
parent 388bba60ff
commit 73f5222876
1 changed files with 297 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

297
doc/source/process/TrademarkProgram.rst Normal file
View File

@ -0,0 +1,297 @@
============================
Trademark Process Definition
============================
.. replaces CoreDefintion.rst.
Objective
=========
The following list represents the "guiding principles" used by the
Foundation Board to determine how commercial implementations of OpenStack
can be granted use of the trademark.
::
Principles Adopted at Oct 4th 2013 Board Meeting
Implementation
==============
* The `Governance/InteropWG
<https://wiki.openstack.org/wiki/Governance/InteropWG/>`_ is
working to manage this.
* Meetings and agendas are linked from that page, including
`Meetpad <https://meetpad.opendev.org/Interop-WG-weekly-meeting>`_
available on `Etherpad <https://etherpad.opendev.org/p/interop>`_
and open to the community.
Principles
==========
.. image:: ../images/500px-Core_flow.png
1. Implementations that are Required Cloud Services can use OpenStack
Trademark (OpenStack™)
1. This is the legal definition of "core" and the why it matters to the
community.
2. We want to make sure that the OpenStack™ mark means something.
3. The OpenStack™ mark is not the same as the OpenStack brand; however,
the Board uses its control of the mark as a proxy to help manage the
brand.
2. Required Cloud Services is a subset of the whole project
1. OpenStack is a broad and diverse community with growing functionality.
This growing functionality is achieved via "projects" that expose
services to create Cloud Computing Platforms. This constant innovation
is vital to OpenStack. The pursuit of this Interop effort is to define
a common stable subset OpenStack functionality that most cloud platform
are using. Not all services, and not all features of chosen services
are required to do that. For OpenStack Logo Program The Open
Infrastructure Foundation defines what projects are required services.
Currently, the list of services consists of:
Nova, Keystone, Neutron, Cinder, Glance and Swift. See
`OpenStack Software page
<https://www.openstack.org/software/project-navigator/openstack-components/#openstack-services>`_.
2. The Interop effort is currently centered around three Platform programs:
- OpenStack Powered Platform,
- OpenStack Powered Compute and
- OpenStack Powered Storage.
Each of these programs have designated sections of OpenStack components
that form an important part of interoperability across implementations.
Alongside these platforms, there are also "add-on" services that extend
the functionality. OpenStack Powered Compute Platform
encompasses designated sections from:
- OpenStack Identity (keystone),
- OpenStack Compute (nova),
- OpenStack Image Storage (glance),
- OpenStack Block Storage (cinder) and
- OpenStack Networking (neutron) services.
The separate add-on guidelines include designated sections of:
- OpenStack DNS (designate),
- OpenStack Orchestration (heat) and
- OpenStack Shared File System Storage (manila) services,
respectively.
3. There are other Add-on Trademarks that are managed together with
the Required Cloud Services by the Open Infrastructure Foundation,
and available for the platform ecosystem as per
the Board’s discretion, and administered by Interop WG.
4. Currently there are three Add-on programs: OpenStack with DNS,
OpenStack with Orchestration, and OpenStack with Shared File System.
These three add Designate, Heat and Manila projects to the Openstack
Powered programs.
5. "OpenStack API Compatible" Trademark is not part of this discussion and
should be not be assumed.
3. Required Cloud Services and Add-on definitions can be applied equally
to all usage models
1. There should not be multiple definitions of OpenStack depending on
the operator (public, private, community, etc)
2. While expected that each deployment is identical, the differences
must be quantifiable
4. Claiming OpenStack requiring use of designated upstream code
1. Implementations claiming the OpenStack™ Trademark must use the OpenStack
upstream code (or be using code submitted to upstream)
2. You are not OpenStack, if you pass all the tests but do not use the
API framework
3. This also surfaces bit-rot in alternate implementations to the larger
community
4. This behavior improves interoperability because there is more shared
code between implementations
5. Projects must have an open reference implementation
1. OpenStack will require an open source reference base plug-in
implementation for projects (if not part of OpenStack, license model
for reference plug-in must be compatible).
2. Definition of a plug-in: alternate backend implementations with a
common API framework that uses common _code_ to implement the API.
That is commonly referred to as a driver.
3. This expects that projects (where technically feasible) are expected
to implement a plug-in or extension architecture.
4. This is already in place for several projects and addresses around
ecosystem support, enabling innovation.
5. Reference plug-ins are, by definition, the complete capability set.
It is not acceptable to have "core" features that are not functional
in the reference plug-in.
6. This will enable alternate implementations to offer innovative or
differentiated features without forcing changes to the reference
plug-in implementation. These are commonly referred to as vendor
drivers.
7. This will enable the reference to expand without forcing other
alternate implementations to match all features and recertify.
6. Vendors may utilize vendor plug-ins as alternative implementations
to reference plug-ins
1. If a vendor plug-in passes all relevant tests then it can be
considered a full substitute for the reference plug-in
2. If a vendor plug-in does NOT pass all relevant test then the vendor
is required to include the open source reference in the
implementation.
3. Vendor plug-in implementations may pass any tests that make sense
4. Vendor plug-in implementations should add tests to validate new
functionality.
5. They must have all the must-pass tests (see #10) to claim the
OpenStack Trademark.
6. OpenStack Implementations are verified by open community tests
7. Vendor OpenStack implementations must achieve 100% of must-have
coverage?
8. Implemented tests can be flagged as may-have requires list.
9. Certifiers will be required to disclose their testing gaps.
10. This will put a lot of pressure on the Tempest project.
11. Maintenance of the testing suite to become a core Open
Infrastructure Foundation responsibility.
This may require additional resources.
12. Implementations and products are allowed to have variation based on
publication of compatibility.
13. Consumers must have a way to determine how the system is different
from reference (posted, discovered, etc.)
14. Testing must respond in an appropriate way on BOTH pass and fail
(the wrong return rejects the entire suite)
15. Vendor plug-in implementations are applicaple to all projects
under Interop programs, both Required Cloud Services and Add-ons.
7. Tests can be remotely or self-administered
1. Plug-in certification is driven by Tempest self-certification model
2. Self-certifiers are required to publish their results
3. Self-certified are required to publish enough information that a 3rd
party could build the reference implementation to pass the tests.
4. Self-certified must include the operating systems that have been
certified
5. It is preferred for self-certified implementation to reference an
OpenStack reference architecture "flavor" instead of defining their
own reference. (a way to publish and agree on flavors is needed)
6. The Open Infrastructure Foundation had defined a mechanism of
dispute resolution. (A trust but verify model)
7. As an ecosystem partner, you have a need to make a "works against
OpenStack" statement that is supportable
8. API consumer can claim working against the OpenStack API if it works
against any implementation passing all the "must have" tests(YES)
9. API consumers can state they are working against the OpenStack API
with some "may have" items as requirements
10. API consumers are expected to write tests that validate their
required behaviors (submitted as "may have" tests)
8. A subset of tests are chosen by the Open Infrastructure Foundation
as "must-pass"
1. How? Read the `Governance/CoreCriteria <./CoreCriteria.rst/>`_ Selection
Process
2. An OpenStack body will recommend which tests are elevated from
may-have to must-have
3. The selection of "must-pass" tests should be based on quantifiable
information when possible.
4. Must-pass tests should be selected from the existing body of
"may-pass" tests. This encourages people to write tests for cases
they want supported.
5. We will have a process by which tests are elevated from may to must
lists
6. Potentially: the User Committee will nominate tests that elevated to
the board
7. OpenStack Powered Trademark means passing all "must-pass" tests
9. The OpenStack board delegated to Interop WG responsibility
to define Trademark criteria – to approve 'musts'.
1. The Interop WG will submit the must-pass tests to the Approval Committee
as a block and passed as a single motion.
2. We are NOT defining which items are on the list in this effort, just
making the position that it is how we will define Required Cloud
Services.
3. May-have tests include items in the integrated release, but which are
not core.
4. Must haves – must comply with the Core criteria defined from the
IncUp committee results
5. Interop WG can propose new Add-on programs for inclusion for OpenStack
Powered Trademark to the Approval Committee.
6. Interop WG must bring to the Open Infrastructure Foundation any major
changes to OpenStack Trademark program for approval. Approval of new
guidelines, adding new projects to Add-on Trademark are not considered
major change to the operation of the OpenStack Trademark program. These
are handled by the Approval Committeei. Process changes,
like the membership of the Approval Committee,
alignment of OpenStack Powered Logo to OpenStack
TC changes to grouping of OpenStack projects into use case scanarios
are examples of major changes that require the Open Infrastructure
Board approval.
10. OpenStack Trademark means passing all "must-pass" tests
1. The Approval Committee owns the responsibility
to define 'guidelines' - to approve 'musts'
2. We are NOT defining which items are on the list in this effort, just
making the position that it is how we will define guideline
3. May-have tests include items in the release, but which
are not core functionality of included projects.
4. Must haves – must comply with the criteria defined in 'guidelines' from
the committee results
5. Projects that are not included in 'the Required Cloud Services'
or 'Add-on' programs
are not to be included in the 'may' or 'must' list