openinfra
/
interop
Code Issues Proposed changes

Prettify .rst docs 

Fixing a few links as the original ones were returning 404.
The commit fixes .rst syntax issues to make the pages
render "nicer". The commit changes only format of the .rst
code, the content of the pages is not changed at all.

Change-Id: Icf0da2d7d1b42b065639c9105fbc16e1999bf630
This commit is contained in:
Martin Kopec 2021-09-14 15:11:29 +02:00
parent 791c95309e
commit 6cb143addd
11 changed files with 51 additions and 58 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
doc/source/process/2021A.rst
View File

@ -10,17 +10,17 @@ process as required by the OpenStack bylaws
and approved by the OpenStack Technical Committee and
Open Infrastructure Foundation Board.
Expected Time line:
---------------------------------------
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 |
+------------+--------------------------------------+---------------------+
| PTG | Review next guidelines | Community |
+------------+--------------------------------------+---------------------+
| PTG | Review status | Interop WG |
+------------+--------------------------------------+---------------------+
| +1 month | Update draft of guidelines | Interop WG |
+------------+--------------------------------------+---------------------+
@ -38,7 +38,7 @@ 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.
@ -87,8 +87,7 @@ A2. Community Groups Tests for Capabilities
7. The Interop Working Group optionally will provide a human-readable summary
of the Guideline generated from the JSON version.
A3. Interop Working Group Collects Recommendations for
Designated Sections
A3. Interop Working Group Collects Recommendations for Designated Sections
1. Designated Sections will not be removed without being deprecated in the
previous Guideline.
@ -130,8 +129,8 @@ A4. Interop Working Group identifies required capabilities
Component. Components will be evaluated based on their use in the
Platform.
A5. The Interop Working Group recommends OpenStack Components and OpenStack Platform
Scope
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.
@ -193,7 +192,7 @@ B3. Changes to Guideline made by Gerrit Review Process
participate in the Gerrit process with attribution.
B4. For Gerrit reviews, Interop Working Group Co-Chairs act as
core reviewers.
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
@ -207,6 +206,7 @@ B4. For Gerrit reviews, Interop Working Group Co-Chairs act as
6. 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.
@ -222,6 +222,7 @@ B5. Projects Interlocks
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
@ -239,6 +240,7 @@ 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
@ -396,6 +398,7 @@ 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

5
doc/source/process/GovernanceProcess.rst
View File

@ -9,8 +9,3 @@ Governance Process
due to time limits. Minutes from prior meetings will be posted to the
`Interop WG wiki page
<https://wiki.openstack.org/wiki/Governance/InteropWG>`_.
* Process documents and other "rules of the road" will be maintained and
voted on in `Gerrit
<http://opendev.org/openstack/defcore>`_. Committee
chairs will have +/-2 voting privilleges.

8
doc/source/process/Lexicon.rst
View File

@ -7,8 +7,8 @@ required capabilities, and including designated sections of code.
There are multiple marks available for vendors depending on which
capability groupings are passed.
TERMS:
----------------------------------------
TERMS
-----
Advisory
Capabilities that have been suggested for the next Guideline.
@ -85,7 +85,7 @@ Participant
documentation, training, product management and other materials.
For Interop Working Group purposes, Participant is not limited to
the community members identified as "ATC" as per
http://opendev.org/openstack/governance/tree/reference/charter.rst#n132
https://governance.openstack.org/tc/reference/charter.html
(see also Technical Leadership)
Platform
@ -107,7 +107,7 @@ Technical Leadership
community to guide the technical direction of the OpenStack project.
These leaders include the Technical Committee (TC) and Project
Technical Leads (PTL).
See: http://opendev.org/openstack/governance/tree/reference/charter.rst
See: https://governance.openstack.org/tc/reference/charter.html
Test
Program that exercises functionality of a component to validate

49
doc/source/process/TrademarkProgram.rst
View File

@ -19,12 +19,9 @@ Implementation
==============
* The `Governance/InteropWG
<https://wiki.openstack.org/wiki/Governance/InteropWG/>`_ is
<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.
* Meetings and agendas are linked from that page and open to the community.
Principles
==========
@ -32,7 +29,7 @@ Principles
.. image:: ../images/500px-Core_flow.png
1. Implementations that are Required Cloud Services can use OpenStack
Trademark (OpenStack™)
Trademark (OpenStack™)
1. This is the legal definition of "core" and the why it matters to the
community.
@ -60,9 +57,9 @@ Principles
2. The Interop effort is currently centered around three Platform programs:
- OpenStack Powered Platform,
- OpenStack Powered Compute and
- OpenStack Powered Storage.
- 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.
@ -70,19 +67,17 @@ Principles
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.
- 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:
The separate add-on guidelines include designated sections of:
- OpenStack DNS (designate),
- OpenStack Orchestration (heat) and
- OpenStack Shared File System Storage (manila) services,
respectively.
- 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,
@ -98,7 +93,7 @@ Principles
should be not be assumed.
3. Required Cloud Services and Add-on definitions can be applied equally
to all usage models
to all usage models
1. There should not be multiple definitions of OpenStack depending on
the operator (public, private, community, etc)
@ -149,7 +144,7 @@ Principles
alternate implementations to match all features and recertify.
6. Vendors may utilize vendor plug-ins as alternative implementations
to reference plug-ins
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
@ -190,7 +185,7 @@ Principles
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
15. Vendor plug-in implementations are applicable to all projects
under Interop programs, both Required Cloud Services and Add-ons.
7. Tests can be remotely or self-administered
@ -225,7 +220,7 @@ Principles
required behaviors (submitted as "may have" tests)
8. A subset of tests are chosen by the Open Infrastructure Foundation
as "must-pass"
as "must-pass"
1. How? Read the `Governance/CoreCriteria <./CoreCriteria.rst/>`_ Selection
Process
@ -249,7 +244,7 @@ Principles
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'.
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.
@ -271,10 +266,10 @@ Principles
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,
are handled by the Approval Committee. 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
TC changes to grouping of OpenStack projects into use case scenarios
are examples of major changes that require the Open Infrastructure
Board approval.

2
doc/source/process/procedure.rst
View File

@ -52,7 +52,7 @@ Recommended Test Procedure
##########################
Follow steps mentioned in the refstack-client's README.rst:
https://opendev.org/openstack/refstack-client
https://opendev.org/openinfra/refstack-client
* Follow 'Environment setup' section to clone and install refstack-client

2
guidelines/2015.07/procedure.rst
View File

@ -40,7 +40,7 @@ or CentOS 7 have been verified) with administrator privileges.
* Download the RefStack client:
``git clone https://opendev.org/openstack/refstack-client``
``git clone https://opendev.org/openinfra/refstack-client``
* In the refstack-client directory, install tempest and required dependencies.
You may specify a specific tag of tempest with the -t option.

2
guidelines/2016.01/procedure.rst
View File

@ -55,7 +55,7 @@ or CentOS 7 have been verified) with administrator privileges.
* Download the RefStack client:
``git clone https://opendev.org/openstack/refstack-client``
``git clone https://opendev.org/openinfra/refstack-client``
* In the refstack-client directory, install tempest and required dependencies.
You may specify a specific tag of tempest with the -t option.

2
guidelines/2016.08/procedure.rst
View File

@ -55,7 +55,7 @@ or CentOS 7 have been verified) with administrator privileges.
* Download the RefStack client:
``git clone https://opendev.org/openstack/refstack-client``
``git clone https://opendev.org/openinfra/refstack-client``
* In the refstack-client directory, install tempest and required dependencies.
You may specify a specific tag of tempest with the -t option.

4
tools/jsonToRst_schema_1.py
View File

@ -78,13 +78,13 @@ with open(outFileName, "w") as outFile:
# Correct Source
if data.get('source') not in (
'http://opendev.org/openstack/defcore/',
'http://opendev.org/openstack/interop/'):
'http://opendev.org/openinfra/interop/'):
print_error("The expected interoperability guideline source not found")
outFile.write("""
:Status: {status}
:Replaces: {replaces}
:JSON Master: http://opendev.org/openstack/interop/raw/branch/master/{id}.json
:JSON Master: http://opendev.org/openinfra/interop/raw/branch/master/{id}.json
This document outlines the mandatory capabilities and designated
sections required to exist in a software installation in order to

2
working_materials/additional_properties_waiver.rst
View File

@ -88,4 +88,4 @@ Details of Waiver
[2] https://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html
[3] http://lists.openstack.org/pipermail/openstack-dev/2015-March/059576.html
[4] https://github.com/openstack/tempest/tree/master/tempest/lib/api_schema/response/compute
[5] http://opendev.org/openstack/refstack-client/
[5] http://opendev.org/openinfra/refstack-client/

6
working_materials/scoring.txt
View File

@ -201,9 +201,9 @@ Notes:
forward [5].
[1] https://bugs.launchpad.net/python-novaclient/+bug/1491579
[2] http://opendev.org/openstack/interop/raw/branch/master/doc/source/process/CoreCriteria.rst#n44
[3] http://opendev.org/openstack/interop/raw/branch/master/doc/source/process/CoreCriteria.rst#n48
[4] http://opendev.org/openstack/interop/raw/branch/master/doc/source/process/CoreCriteria.rst#n90
[2] http://opendev.org/openinfra/interop/raw/branch/master/doc/source/process/CoreCriteria.rst#n44
[3] http://opendev.org/openinfra/interop/raw/branch/master/doc/source/process/CoreCriteria.rst#n48
[4] http://opendev.org/openinfra/interop/raw/branch/master/doc/source/process/CoreCriteria.rst#n90
[5] http://eavesdrop.openstack.org/meetings/defcore_flag_14/2015/defcore_flag_14.2015-09-09-15.03.log.html#l-13
Image