e809580088
The next patch actually describes desired state of version discovery. But in an epic amount of cart-before-the-horse, we have the process for consuming the discovery already because the process must take in to account the present as well as the past. This process has kept in mind what consuming the recommended discovery process _wants_ to look like in the future and in calls that out in a few places. The intent would be that the algorithm here would work for all clouds, but that as clouds and services adopt API-SIG recommendations, the interactions with the clouds would become more efficient. (so for clients using the complete algorithm they should be upwards compatible with forthcoming API-SIG guidelines and will just naturally do less work over time). I believe this is consistent in defaults, fallbacks and error conditions with what is currently implemented in keystoneauth, although there is additional logic presented here which is not yet in keystoneauth. The intent is for the process presented here to not change the behavior experienced by current keystoneauth users, with the exception that when the complete algorithm is implemented it's possible that an additional API call may be made on older clouds. That is to say, keystoneauth should not need to make any incompatible changes, but may need to add some features to be a fully compliant implementation. Apologies for the size and complexity. It turns out there are many historical oddities still lurking out there and advice to client authors that does not take them in to account would be incomplete. On the other hand, as we drive guidelines forward into being implemented, the need for this much crazy logic should go away. Co-Authored-By: Dmitry Tantsur <divius.inside@gmail.com> Change-Id: I241f76bca8ac27fc3d27028ae284b9012a2da7e9
2.0 KiB
2.0 KiB
Consuming Service Types Authority
The OpenStack Service Types Authority is data about official service type names and historical service type names commonly in use from before there was an official list. It is made available to allow libraries and other client API consumers to be able to provide a consistent interface based on the official list but still support existing names. Providing this support is highly recommended, but is ultimately optional. The first step in the matching process is always to return direct matches between the catalog and the user request, so the existing consumption models from before the existence of the authority should always work.
In order to consume the information in the OpenStack Service Types Authority it is important to know a few things:
- The data is maintained in YAML format in git. This is the ultimately authoritative source code for the list.
- The data is published in JSON format at https://service-types.openstack.org/service-types.json and has a JSONSchema at https://service-types.openstack.org/published-schema.json.
- The published data contains a version which is date based in ISO Date Time Format, a sha which contains the git sha of the commit the published data was built from, and pre-built forward and reverse mappings between official types and aliases.
- The JSON file is served with ETag support and should be considered highly cacheable.
- The current version of the JSON file should always be the preferred file to use.
- The JSON file is similar to timezone data. It should not be considered versioned such that stable releases of distros should provide a frozen version of it. Distro packages should instead update for all active releases when a new version of the file is published.