Switch to newer openstackdocstheme version

Switch to openstackdocstheme 2.2.1 version. Using
this version will allow especially:
* Linking from HTML to PDF document
* Allow parallel building of documents
* Fix some rendering problems

Update Sphinx version as well.

Disable openstackdocs_auto_name to use 'project' variable as name.

Change pygments_style to 'native' since old theme version always used
'native' and the theme now respects the setting and using 'sphinx' can
lead to some strange rendering.

openstackdocstheme renames some variables, so follow the renames
before the next release removes them. A couple of variables are also
not needed anymore, remove them.

See also
http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014971.html

Fix problems found by newer Sphinx version.

Change-Id: I480437115b4f216b28b87f2addf34721a8d27bd7

doc/requirements.txt

@@ -1,6 +1,6 @@
 # The order of packages is significant, because pip processes them in the order
 # of appearance. Changing the order has an impact on the overall integration
 # process, which may cause wedges in the gate later.
-openstackdocstheme>=1.27.1 # Apache-2.0
+openstackdocstheme>=2.2.1 # Apache-2.0
 doc8>=0.6.0 # Apache-2.0
-sphinx!=1.6.6,!=1.6.7,>=1.6.2 # BSD
+sphinx>=2.0.0,!=2.1.0 # BSD

doc/source/arch-requirements/arch-requirements-enterprise.rst

@@ -184,7 +184,7 @@ Input-Output requirements
 Scale
  Scaling storage solutions in a storage-focused OpenStack
  architecture design is driven by initial requirements, including
- :term:`IOPS <Input/output Operations Per Second (IOPS)>`, capacity,
+ :term:`IOPS <Input/Output Operations Per Second (IOPS)>`, capacity,
  bandwidth, and future needs. Planning capacity based on projected needs
  over the course of a budget cycle is important for a design. The
  architecture should balance cost and capacity, while also allowing

doc/source/arch-requirements/arch-requirements-operations.rst

@@ -45,7 +45,8 @@ have differences in implementation.
 To segregate traffic, allow applications to create a private tenant
 network for database and storage network traffic. Use a public network
 for services that require direct client access from the Internet. Upon
-segregating the traffic, consider :term:`quality of service (QoS)` and
+segregating the traffic, consider :term:`quality of service (QoS)
+<Quality of Service (QoS)>` and
 security to ensure each network has the required level of service.
 
 Also consider the routing of network traffic. For some applications,

doc/source/common/glossary.rst

@@ -807,7 +807,7 @@ C
       compression for things such as Object Storage objects or Image service
       VM images.
 
-   Compute API (Nova API)
+   Compute API (nova API)
 
       The nova-api daemon provides access to nova services. Can communicate with
       other APIs, such as the Amazon EC2 API.
@@ -2547,7 +2547,7 @@ N
 
    neutron
 
-      Codename for OpenStack :term:`Networking service <Networking Service
+      Codename for OpenStack :term:`Networking service <Networking service
       (neutron)>`.
 
    neutron API
@@ -3739,7 +3739,7 @@ T
    tacker
 
       Code name for the :term:`NFV Orchestration service <NFV Orchestration
-      service (tacker)>`
+      Service (tacker)>`
 
    Telemetry service (telemetry)
 

doc/source/conf.py

@@ -54,8 +54,8 @@ source_suffix = '.rst'
 master_doc = 'index'
 
 # General information about the project.
-repository_name = "openstack/arch-design"
-use_storyboard = True
+openstackdocs_repo_name = "openstack/arch-design"
+openstackdocs_use_storyboard = True
 copyright = u'2015-2018, OpenStack contributors'
 
 # The version info for the project you're documenting, acts as replacement for
@@ -97,7 +97,7 @@ exclude_patterns = ['common/cli*', 'common/nova*', 'common/get-started-*']
 # show_authors = False
 
 # The name of the Pygments (syntax highlighting) style to use.
-pygments_style = 'sphinx'
+pygments_style = 'native'
 
 # A list of ignored prefixes for module index sorting.
 # modindex_common_prefix = []

doc/source/design-networking/design-networking-concepts.rst

@@ -185,7 +185,8 @@ architecture include:
 * There are a variety of well tested tools, such as Internet Control Message
   Protocol (ICMP) to monitor and manage traffic.
 
-* Layer-3 architectures enable the use of :term:`quality of service (QoS)` to
+* Layer-3 architectures enable the use of :term:`quality of service
+  (QoS) <Quality of Service (QoS)>` to
   manage network performance.
 
 Layer-3 architecture limitations