Data for the OpenStack project navigator
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
OpenDev Sysadmins 2b3bb5b5cb OpenDev Migration Patch 2 months ago
releases Add nova entry for queens 1 year ago
.gitignore Add jsonschema and validation script 2 years ago
.gitreview OpenDev Migration Patch 2 months ago
.zuul.yaml import zuul job settings from project-config 10 months ago
README.rst Add API version history for Nova 2 years ago
schema.json Add API version history for Nova 2 years ago
setup.cfg Add jsonschema and validation script 2 years ago
setup.py Add jsonschema and validation script 2 years ago
tox.ini Add jsonschema and validation script 2 years ago
validate.py Add jsonschema and validation script 2 years ago

README.rst

Project Navigator Data

Each release should contain a file for each Official OpenStack service that should contain an extraction from the default version discovery document for that service for that release. The file can be maintained by hand, but the following describes how to derive the contents for each service from a running copy of the service.

Each file shold be named after the service name, e.g. "cinder".

The structure of each file is the same as in the API WG document on version discovery, minus the links section, which obviously does not make sense for the project navigator.

Each service dictionary should contain a top level dictionary with a key versions that contains a list of dictionaries that have the following keys:

  • status, required: can be one of CURRENT, SUPPORTED, DEPRECATED, EXPERIMENTAL
  • id, required: the major api version, in the form vX.X
  • max_version, optional: the maximum microversion supported, in the form X.XX
  • version, optional: same as max_version
  • min_version, optional: the minimum microversion supported, in the form X.XX

If either min_version or max_version are given, they both must be given. If the service does not have microversions, they should be omitted.

This is also expressed in jsonschema form in the file schema.json in this repository.

Process Description

object-store doesn't have version discovery document, so it must just be hard coded.

For the rest of the services, fetch the version discovery document via "GET /" on the service.

If the service is compute, image, network or share, the list of versions is found in a top level dictionary named 'versions'.

If the service is identity, container_infra or key_manager, the list of versions is in the 'values' key under the 'versions' key.

For each version in the list of versions, grab status and id, and then grab max_version and min_version if they exist. If max_version does not exist but version does, grab version.

status values should be uppercased.

If service is identity and status is "stable", change it to "CURRENT".

If reading pseudo python is easier. This assumes a list called service_types, a requests Session called client, a dict of service endpoints called endpoints and a dict that is a mapping of service names keyed by service_type called service_names.

In-repo Maintenance

If each projects wants to maintain a document with the list of versions for a given release, then updating the version file is a simple matter of a script to run over the branches of the repos to produce the data.