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
parent
791c95309e
commit
6cb143addd
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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/
|
||||
|
||||
@ -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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user