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

doc/source/process/2021A.rst

@@ -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 next guidelines               | Community           |
-+  PTG       +--------------------------------------+---------------------+
++------------+--------------------------------------+---------------------+
-|            | Review status                        | Interop WG          |
+| 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
+A3. Interop Working Group Collects Recommendations for Designated Sections
-    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
+A5. The Interop Working Group recommends OpenStack Components and OpenStack
-    Scope
+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

doc/source/process/GovernanceProcess.rst

@@ -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.

doc/source/process/Lexicon.rst

@@ -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

doc/source/process/TrademarkProgram.rst

@@ -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
+* Meetings and agendas are linked from that page and open to the community.
-  `Meetpad <https://meetpad.opendev.org/Interop-WG-weekly-meeting>`_
-  available on `Etherpad <https://etherpad.opendev.org/p/interop>`_
-  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 Platform,
-- OpenStack Powered Compute and
+      - OpenStack Powered Compute and
-- OpenStack Powered Storage.
+      - 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 Identity (keystone),
-- OpenStack Compute (nova),
+      - OpenStack Compute (nova),
-- OpenStack Image Storage (glance),
+      - OpenStack Image Storage (glance),
-- OpenStack Block Storage (cinder) and
+      - OpenStack Block Storage (cinder) and
-- OpenStack Networking (neutron) services.
+      - 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 DNS (designate),
-- OpenStack Orchestration (heat) and
+      - OpenStack Orchestration (heat) and
-- OpenStack Shared File System Storage (manila) services,
+      - OpenStack Shared File System Storage (manila) services, respectively.
-
-        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.
 

doc/source/process/procedure.rst

@@ -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
 

guidelines/2015.07/procedure.rst

@@ -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.

guidelines/2016.01/procedure.rst

@@ -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.

guidelines/2016.08/procedure.rst

@@ -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.

tools/jsonToRst_schema_1.py

@@ -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

working_materials/additional_properties_waiver.rst

@@ -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/

working_materials/scoring.txt

@@ -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
+[2] http://opendev.org/openinfra/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
+[3] http://opendev.org/openinfra/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
+[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