Created new process 2021A to replace 2017A one
https://opendev.org/osf/interop/src/branch/master/doc/source/process/2017A.rst Transition guidelines approval process from tha OIF board to committee consisting of Interop WG, Refstack, TC and Foundation Marketplace manager. Add-on programs are formally included. Updated index file. Change-Id: Ic55f40dd5f61eefed12f458593f39bc883c41bd9
This commit is contained in:
ArkadyKanevsky
parent
388bba60ff
commit
33160b11c8
@ -9,7 +9,7 @@ Process Documentation
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
process/2016A.rst
|
||||
process/2021A.rst
|
||||
|
||||
=====================
|
||||
Schema Documentation
|
||||
@ -18,7 +18,7 @@ Schema Documentation
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
schema/1.5.rst
|
||||
schema/2.0.rst
|
||||
|
||||
=================
|
||||
Active Guidelines
|
||||
|
||||
417
doc/source/process/2021A.rst
Normal file
417
doc/source/process/2021A.rst
Normal file
@ -0,0 +1,417 @@
|
||||
OpenStack Interop Working Group Process 2021A
|
||||
==============================================
|
||||
|
||||
:Status: Draft
|
||||
:Replaces: 2017A
|
||||
|
||||
This document describes the Interop Working Group's working
|
||||
process as required by the OpenStack bylaws
|
||||
(see `<https://www.openstack.org/legal/bylaws-of-the-openstack-foundation/>`_)
|
||||
and approved by the OpenStack Technical Committee and
|
||||
Open Infrastructure Foundation Board.
|
||||
|
||||
Expected Time line:
|
||||
---------------------------------------
|
||||
|
||||
+------------+--------------------------------------+---------------------+
|
||||
| Time Frame | Activities | Lead By |
|
||||
+============+======================================+=====================+
|
||||
| -1 month | Draft of next guidelines. | Interop WG |
|
||||
+------------+-----------+--------------------------+---------------------+
|
||||
| | Review next guidelines | Community |
|
||||
+ PTG +--------------------------------------+---------------------+
|
||||
| | Review status | Interop WG |
|
||||
+------------+--------------------------------------+---------------------+
|
||||
| +1 month | Update draft of guidelines | Interop WG |
|
||||
+------------+--------------------------------------+---------------------+
|
||||
| +2 months | Testing draft guidelines | Refstack, Vendors |
|
||||
+------------+--------------------------------------+---------------------+
|
||||
| +3 months | Approve Guidance | approval_committee_ |
|
||||
+------------+--------------------------------------+---------------------+
|
||||
|
||||
Note: Time line is aligned with releases schedules.
|
||||
See `<https://releases.openstack.org/xena/schedule.html>`_ as example of
|
||||
Xena schedule. Draft is done during the release for which guideline is
|
||||
being developed, while its completion is done during next release
|
||||
schedule.
|
||||
The Interop Working Group may accelerate the process to correct errors
|
||||
and omissions.
|
||||
|
||||
Process Definition
|
||||
--------------------------------------
|
||||
|
||||
The Guideline process has four primary phases: Draft, Review, Validation
|
||||
and Approval.
|
||||
- During the Draft phase (A), the Interop Working Group
|
||||
creates new draft of guideline with input from the community
|
||||
with updated coverage, scores of the components, and other details.
|
||||
- During the Review phase (B), guidelines for each project are reviewed
|
||||
during the PTG with that project, input from refstack community,
|
||||
and general feedback from the community and vendors.
|
||||
- During the Validation phase (C) Guidelines go through and implementation
|
||||
and testing cycle.
|
||||
- Finally, Approval by approval_committee_
|
||||
|
||||
The Open Infrastructure Board of Directors is not involved
|
||||
in the guideline process and review, and approve only changes to the
|
||||
Interop WG process.
|
||||
|
||||
This section provides specific rules and structure for each phase.
|
||||
|
||||
Guidelines Draft Phase (A)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Starting: S-1
|
||||
|
||||
A1. New Guidelines Start From Previous Guidelines
|
||||
|
||||
1. New Guidelines start from the previously approved Guidelines document.
|
||||
2. New Guidelines are given the preliminary name of "next.json".
|
||||
3. For each of the new Guidelines add-on component there is
|
||||
a separate "next.json" document.
|
||||
|
||||
A2. Community Groups Tests for Capabilities
|
||||
|
||||
1. The Interop Working Group coordinates community
|
||||
activities with the Technical Leadership to revise the capabilities
|
||||
based on current technical needs and functionality.
|
||||
2. Capabilities must be a subset of the OpenStack Technical Committee
|
||||
Approved Release as determined by the Board of Directors
|
||||
(see bylaws of the Foundation, section 4.1(b)(iii)).
|
||||
3. Groupings may change between iterations.
|
||||
4. Tests must have unique identifiers that are durable across releases
|
||||
and changes in grouping.
|
||||
5. Tests must be under OpenStack Technical Committee governance.
|
||||
6. The Interop Working Group will provide the test groupings
|
||||
in JSON format for scoring.
|
||||
7. The Interop Working Group will provide a human-readable summary
|
||||
of the Guideline generated from the JSON version.
|
||||
[AI: Update tooling for it]
|
||||
|
||||
A3. Interop Working Group Collects Recommendations for
|
||||
Designated Sections
|
||||
|
||||
1. Designated Sections will not be removed without being deprecated in the
|
||||
previous Guideline.
|
||||
2. Designated Sections will not be added without being advisory in the
|
||||
previous Guideline.
|
||||
3. Designated Sections will not be added or be made advisory unless the
|
||||
corresponding code base is a subset of the OpenStack Technical Committee
|
||||
Approved Release as determined by the Board of Directors
|
||||
(see bylaws of the Foundation, section 4.1(b)(iii)).
|
||||
4. TC & PTLs may, but is not required to, assist the
|
||||
Interop Working Group with defining advisory Designated
|
||||
Sections for projects that have advisory or required Capabilities.
|
||||
5. Designated Sections may be sufficiently defined for Guidelines using
|
||||
general descriptions.
|
||||
6. The Interop Working Group will present A3.4 descriptions to
|
||||
approval_committee_ for approval.
|
||||
7. TC & PTLs may, but is not required to, provide more specific
|
||||
details describing the Designated Sections for a project.
|
||||
8. Designated Sections will be included in the JSON Guideline.
|
||||
|
||||
A4. Interop Working Group identifies required capabilities
|
||||
|
||||
1. The Interop Working Group uses Board approved scoring criteria
|
||||
`scoring criteria <https://opendev.org/osf/interop/src/branch/master/doc/source/process/CoreCriteria.rst>`_
|
||||
to evaluate Capabilities.
|
||||
2. The Interop Working Group needs Board approval to change
|
||||
scoring criteria.
|
||||
3. Scoring criteria factors or weights cannot change after Draft is
|
||||
published.
|
||||
4. The Interop Working Group identifies a cut-off score for
|
||||
determining that a Capability is required.
|
||||
5. Capabilities will not be removed without being deprecated in the
|
||||
previous Guideline.
|
||||
6. Capabilities will not be added without being advisory in the previous
|
||||
Guideline.
|
||||
7. For the "widely deployed" adoption criteria, the size of the
|
||||
pool being considered will match the scope of the community being
|
||||
considered. Capabilities will be evaluated based on their use in their
|
||||
Component. Components will be evaluated based on their use in the
|
||||
Platform.
|
||||
|
||||
A5. The Interop Working Group recommends OpenStack Components and OpenStack Platform
|
||||
Scope
|
||||
|
||||
1. The Interop Working Group recommends Capabilities to include
|
||||
in each OpenStack Component.
|
||||
2. The Interop Working Group recommends which Components are required for
|
||||
the OpenStack Powered Platform.
|
||||
3. The Interop Working Group will apply the approved scoring criteria to
|
||||
evaluate if a component should be included in the
|
||||
Platform (see A4).
|
||||
|
||||
A6. Additional Capabilities and Tests
|
||||
|
||||
1. The Interop Working Group will work with the OpenStack community to
|
||||
define new Capabilities.
|
||||
2. Test grouping for new Capabilities will be included in the
|
||||
Interop Working Group documents.
|
||||
3. The Interop Working Group will publish a list of missing
|
||||
Capabilities and Capabilities with inadequate test coverage.
|
||||
4. Interop Working Group in conjuction with TC and Foundation Marketplace
|
||||
product owner can propose additional Add-on component
|
||||
guidelines.
|
||||
5. Each Add-on is provided as a seperate additional guideline,
|
||||
that follows the same process as "OpenStack powered" ones
|
||||
as defined by this document.
|
||||
|
||||
A7. The Interop Working Group creates recommendation for Draft.
|
||||
|
||||
1. The Interop Working Group coordinates activities to create
|
||||
the Guideline draft.
|
||||
2. The Interop Working Group may choose to ignore recommendations
|
||||
with documented justification.
|
||||
|
||||
Guidelines Review Phase (B)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Starting: PTG
|
||||
|
||||
B1. All Reference Artifacts are reviewed via Gerrit
|
||||
|
||||
1. Draft Guideline
|
||||
2. Designated sections
|
||||
3. Test-Capability groupings
|
||||
4. Flagged Test List
|
||||
5. Capability Scoring criteria and weights
|
||||
6. May not be in Gerrit: Working materials (spreadsheets, etc)
|
||||
|
||||
B2. Presentation of Draft Guidelines for Review
|
||||
|
||||
1. The Interop Working Group will distribute Draft Guidelines
|
||||
to the OpenStack community for review.
|
||||
2. A link to the Gerrit document must be provided with the review materials.
|
||||
3. The draft Guidelines will consist of single document for
|
||||
"OpenStack-Powered" Logo and separate document for each
|
||||
of the add-ons components.
|
||||
|
||||
B3. Changes to Guideline made by Gerrit Review Process
|
||||
|
||||
1. Guidelines proposal and review must go through Gerrit.
|
||||
2. The Interop Working Group will proxy for users who do not
|
||||
participate in the Gerrit process with attribution.
|
||||
|
||||
B4. For Gerrit reviews, Interop Working Group Co-Chairs act as
|
||||
core reviewers.
|
||||
|
||||
1. Interop Working Group Co-Chairs serve as "core" reviewers (+2).
|
||||
2. Requests for changes must be submitted as patches by the requesting
|
||||
party.
|
||||
3. Interop Working Group members may proxy change requests as
|
||||
long as the requesting party is explicitly acknowledged.
|
||||
4. One Interop Working Group Co-Chair must be an Open Infrastructure
|
||||
Foundation Board member.
|
||||
5. One Co-Chair of Interop Working Group is nominated by
|
||||
the Open Infrastructure Board of Directors.
|
||||
6. One Interop Working Group Co-Chair will be elected by the
|
||||
Interop Working Group. Election quorum is composed of
|
||||
attendees present during the election meeting.
|
||||
7. Additional core reviewers (+2) can be appointed by Co-Chairs.
|
||||
8. Election meetings must be posted at least one meeting prior.
|
||||
|
||||
B5. Projects Interlocks
|
||||
1. For the PTG, the Interop Working Group requests a meeting
|
||||
with each project under the "OpenStack Powered" guideline and
|
||||
each of the add-on guidelines.
|
||||
2. Project meeting covers a review of the current guidelines
|
||||
for the projects, any changes/addition/deprecation/removal of
|
||||
APIs. Tests must be available in repositories under
|
||||
OpenStack TC governance. The tests cannot be in repositories
|
||||
outside of list in the openstack governance repository:
|
||||
`<https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml>`_
|
||||
3. Project meeting covers any test result for specific
|
||||
drivers of that project to ensure consistent functionality
|
||||
coverage for all required and designated interoperability
|
||||
functionality of the project.
|
||||
|
||||
B6. Draft Guidelines update
|
||||
1. Following the PTG meeting the Interop Working Group updates
|
||||
draft Guidelines using feedback from each of the projects.
|
||||
2. Ensure any new or modified guidelines must have the corresponding
|
||||
test(s) in Tempest or Tempest plugins, and Refstack wrapper
|
||||
include it.
|
||||
3. For any new add-on program Refstack need to be able to collect
|
||||
submissions for marketplace.
|
||||
4. For any new add-on programs Foundation Marketplace product
|
||||
owner need to prepare ability to issue, record and administer
|
||||
new add-on Logo under Marketplace program.
|
||||
|
||||
Validation (C)
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
Starting: S and continues until S+2
|
||||
|
||||
C0. RefStack validation
|
||||
1. Refstack makes necessary changes to `Page <https://refstack.openstack.org/#/>`_
|
||||
2. Refstack makes necessary changes to handle new guidelines.
|
||||
3. Refstack representative share test results of new guidelines
|
||||
on default platform with Interop Working Group.
|
||||
4. Refstack flags any tests that do not pass on the default platform.
|
||||
|
||||
C1. Vendor Self-Tests
|
||||
|
||||
1. Vendors are responsible for executing tests identified by the
|
||||
Interop Working Group.
|
||||
2. The Interop Working Group may, but is not required to, provide tooling for
|
||||
running tests through Refstack.
|
||||
3. The Interop Working Group may, but is not required to, define a required
|
||||
reporting format.
|
||||
4. Self-test results may be published by Vendors in advance of Open
|
||||
Infrastructure Foundation Marketplace manager review,
|
||||
but must be clearly labeled as "Unofficial Results - Not Yet
|
||||
Accepted By The Open Infrastructure Foundation".
|
||||
5. Vendors who publish self-tests MUST provide them in the same format that
|
||||
would be submitted to the Open Infrastructure Foundation
|
||||
but MAY provide additional formats if they choose to do so.
|
||||
6. Self-test results cannot be used as proof of compliance.
|
||||
|
||||
C2. Vendor submits results to Foundation for review
|
||||
|
||||
1. The Open Infrastructure Foundation Marketplace manager
|
||||
determines the acceptable format for submissions.
|
||||
2. The Open Infrastructure Foundation Marketplace manager
|
||||
has final authority to determine if Vendor meets criteria.
|
||||
3. The Open Infrastructure Foundation Marketplace manager
|
||||
will provide a review of the results within 30 days.
|
||||
4. Vendors can submit results for "OpenStack Powered" Logo
|
||||
and any of the add-on programs together or separately.
|
||||
5. The Open Infrastructure Foundation Marketplace manager
|
||||
can provide review of the results for all vendor
|
||||
submissions together or separately for each Logo.
|
||||
|
||||
C3. Vendor Grievance Process
|
||||
|
||||
1. Vendors may raise concerns with specific tests to the Interop
|
||||
Working Group.
|
||||
2. The Interop Working Group may choose to remove tests from
|
||||
a Guideline (known as flagging).
|
||||
3. The Interop Working Group will acknowledge vendor requests
|
||||
to flag tests within 30 days.
|
||||
|
||||
C4. Results of Vendor Self-Tests will be open
|
||||
|
||||
1. The Open Infrastructure Foundation Marketplace manager
|
||||
will make the final results of approved vendors
|
||||
available to the community.
|
||||
2. The Open Infrastructure Foundation Marketplace manager
|
||||
will not publish incomplete or unapproved results.
|
||||
3. Only "pass" results will be reported. Skipped and failed results will
|
||||
be omitted from the reports.
|
||||
4. Reports will include individual test results, not just Capability
|
||||
scoring.
|
||||
5. Vendors are required to submit a description of the system and
|
||||
configuration used to achieve the results.
|
||||
|
||||
C5. API Usage Data Report
|
||||
|
||||
1. The Open Infrastructure Foundation Marketplace manager
|
||||
will provide the Interop Working Group with an
|
||||
open report about API usage based on self-tests based on
|
||||
Refstack submitted results.
|
||||
2. To the extent the data is available, Capabilities beyond the
|
||||
Interoperability Guideline list will be included in the report.
|
||||
|
||||
C6. Only Two Approved Guidelines at a time:
|
||||
|
||||
1. Vendors seeking validation are limited to using the two
|
||||
latest approved Guidelines.
|
||||
|
||||
2. Since past validations are respected, older Guidelines will be
|
||||
maintained as superseded for historical reference.
|
||||
|
||||
3. Guideline status progresses as follows:
|
||||
|
||||
:draft: initial work, pre-PTG discussion material
|
||||
:review: as presented at the PTG (S) for community review
|
||||
:approved: Committee approved, one of the two official guidelines
|
||||
:superseded: Committee approved, now superseded by two latest guidelines
|
||||
|
||||
Guideline Approval (D)
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Starting: S+3 or earlier
|
||||
|
||||
.. _approval_committee:
|
||||
|
||||
D0. Approval Committee
|
||||
|
||||
1. Approval Committee consists of representatives from 4 bodies
|
||||
|
||||
a. Interop Working Group Co-chairs are approval authority of
|
||||
this committee.
|
||||
b. Refstack core member or presentative(s) as advisory member
|
||||
c. Open Infrastructure Foundation Marketplace product owner as
|
||||
advisory member
|
||||
d. OpenStack TC representative(s) as advisory member
|
||||
|
||||
D1. Committee will review and approve Interoperability Guidelines from draft
|
||||
|
||||
1. Interop Working Group must approve the proposed guidelines.
|
||||
2. Foundation staff member(s) and OpenStack TC member(s) vote in
|
||||
advisory capacity but do not have veto power.
|
||||
3. The approval is done through formal vote and its results recorded
|
||||
with the date of Approval.
|
||||
4. Upon approval guideline document is marked as approved with the
|
||||
date of approval.
|
||||
5. approval_committee_ members may request delay of the formal vote till
|
||||
foundation staff and/or Refstack is capable of handling new guidelines.
|
||||
6. Delay of the vote can be resolved by at most 1 month prior to
|
||||
next PTG meeting, which is the start of work on the new
|
||||
guidelines.
|
||||
7. Guidelines are set at the Platform, Component and
|
||||
Capability level only.
|
||||
8. The Interop Working Group will submit the human-readable
|
||||
summary of Capabilities (see section A2[6]) to the Committee for approval.
|
||||
9. By voting to approve the summary, the Committee delegates responsibility
|
||||
for maintaining test groupings to the Interop Working Group
|
||||
subject to the limitations described in section D2.
|
||||
10. Guidelines only apply to the identified releases (a.k.a. release
|
||||
tags).
|
||||
11. The Add-on Guidelines are set for OpenStack projects in addition
|
||||
to "OpenStack Powered" ones.
|
||||
12. All guidelines follow the same review and approval process
|
||||
irrespective if they are "OpenStack Powered" or "OpenStack Add-on"
|
||||
guidelines.
|
||||
|
||||
D2. Interop Working Group has authority on test categorization
|
||||
|
||||
1. The Interop Working Group can add flagged tests before and
|
||||
after Guideline approval.
|
||||
2. The Interop Working Group cannot add additional Tests to
|
||||
Capability mappings after approval.
|
||||
3. The Interop Working Group maintains the test to Capability
|
||||
mappings in the JSON representation.
|
||||
|
||||
D3. Designated Sections only enforced for projects with required Capabilities
|
||||
|
||||
1. Designated Sections may be defined for any project.
|
||||
2. Designated Sections apply to the releases (a.k.a. release tags)
|
||||
identified in the Guideline.
|
||||
3. Designated Sections will be included in the JSON Capabilities file
|
||||
to ensure a single source of identification.
|
||||
|
||||
D4. Guidelines are named based on the date of Board approval
|
||||
|
||||
1. Naming pattern will be: 4-digit year, dot (period), and 2-digit month.
|
||||
|
||||
Process Change
|
||||
--------------
|
||||
|
||||
E1. Process Draft
|
||||
1. Any process change follows the process of draft, review and approval.
|
||||
2. Any process changes are handled thru gerrit process.
|
||||
3. Proposed changes submitted to Gerrit for review by
|
||||
Interop Working Group as a draft document.
|
||||
4. Interop Working Group adds all Committee members for review of the draft.
|
||||
5. Once that draft is approved, Interop Working Group co-chairs present it to
|
||||
OpenStack Board for approval.
|
||||
6. Once Board approved the changes the new process is marked as
|
||||
approved and is linked from `Interop WG wiki page
|
||||
<https://wiki.openstack.org/wiki/Governance/InteropWG>`_.
|
||||
|
||||
Functional Information
|
||||
----------------------
|
||||
:Format: RestructuredText
|
||||
:Layout: 1.0
|
||||
Loading…
Reference in New Issue
Block a user