Switch to openstackdocstheme 2.2.1 and reno 3.1.0 versions. Using
these versions 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
Change-Id: I0057fe10b462ce5ae430b9ad01e8f7d72be0f13a
Some options are now automatically configured by the version 1.20:
- project
- html_last_updated_fmt
- latex_engine
- latex_elements
- version
- release.
Change-Id: I34b5d91bb5eea3680d915a262bee4a24e2ae2752
1. Sync sphinx dependency with global requirements. It caps python 2 since
sphinx 2.0 no longer supports Python 2.7.
2. Update some URLs to latest
3. Remove unncessary "=="
Change-Id: I48206450371b557f51b0842976d48c9042173df2
The ServiceTypes class is the main entry point for python programmers.
It should allow them to answer the questions they have about the data
without necessarily walking the structure. It can also return the raw
structure if people want to get at it.
We need to know the project codename for services for doing API doc
publication validation and also for being able to send legacy
microversion headers. The information is in the data, use it.
In order to construct and send microversion headers for projects with
aliases, we need to know ALL of the aliases plus the official name,
because we don't know which one of the values will be the correct name
the service is looking for for a given version. The microversion spec,
however, requires that consumers be able to handle a header that
contains a list of services and to ignore the ones it isn't looking for.
By providing a a list of all the possible values we make it easy to
construct a header for a service given a service_type that should work
for all known identifiers of the service and that is future compatible
with the service-type and microversion specifyier aligning.
Co-Authored-By: Doug Hellmann <doug@doughellmann.com>
Change-Id: I57641c9e3c27688b6d7709b1bb07292740d26659
Hervé Beraud