[Openstack-api-consumers] Consuming the service catalog and endpoints get list of supported enpoints *and* supported API versions for each

Monty Taylor mordred at inaugust.com
Wed Jul 19 19:44:01 UTC 2017


On 07/20/2017 03:32 AM, Steve Gordon wrote:
> Hi folks,
> 
> David Flanders highlighted the existence of this list to me, and also the Consuming Service Catalog [1] document - which is somewhat relevant to what I'm trying to achieve but I need something a step beyond that. What I'm interested in once I have worked out all of the endpoints a given service catalog lists, is there a standard way (or a tool) to interrogate those endpoints to get the API versions each supports (both by default, and in general).

WELL ...

We just landed all of the patches to keystoneauth to make sure that it 
can do this consistently for every OpenStack service and expose that 
information. That will be in the next release. We also updated the docs 
on how to consume the data.

This includes discovering what versions are available as well as what 
microversion ranges each service supports.



> I had hacked up some basic BASH/Python to attempt this some time back but from recollection found that keystone's endpoint returned this information in a slightly different JSON structure than other endpoints (also different values like stable versus current for status of an API's support) and that some endpoints returned this without auth while others didn't. I'm assuming I'm not the only one to ever want to do this though so wondering if there is a tool somewhere that already encapsulates this?

Exactly.

As soon as we cut the next keystoneauth release (like, tomorrow) I'll be 
updating os-client-config to use it and then will add a CLI tool to do 
exactly what you're asking - "please dump the complete list of services 
and version information for this cloud"

> The actual problem I'm trying to solve, with my downstream product guy hat on, is that for a given build of Red Hat OpenStack I want to expose somewhere documentation (ideally automatically generated) as to what API versions were enabled and supported by default. This information appears in the marketplace per major version but this AFAIK is both manually curated (I've been asked by our marketing folks to confirm inputs for it in the past) - so prone to error - and focuses on major/minor version numbers when microversions are becoming increasingly important in a number of projects (e.g. if my app wants to use device role tagging w/ Nova I have to be very specific about which microversions are available for me to use as they have different "features"/opportunities for failure).

There is an additional spec that I've been working on to define a "cloud 
profile" that clouds can host that will include all of this in a 
one-stop-shop place so that having the info isn't limited to 
os-client-config users:

https://review.openstack.org/#/c/459869/

I need to go update it based on feedback so far - and I need to explain 
why having a single document people can count on that contains 
pre-cached and consistent version discovery information is valuable a 
bit better.

Long story short - I couldn't agree with you more and we've been working 
a bunch on the underpinnings this cycle (writing docs/specs and then 
getting base openstack libs to actually do the right thing and expose 
the information that has been there for ages but not available because 
the python-*client libs are bong)

https://review.openstack.org/#/q/topic:version-discovery

contains the giant pile of patches associate with this.

You also probably want to get up to speed on these:

https://review.openstack.org/#/c/459405/
http://specs.openstack.org/openstack/api-wg/guidelines/consuming-catalog.html
https://service-types.openstack.org/

The 'consuming version discovery' spec is basically what we just got 
implemented in keystoneauth- need to go back and make sure it's up to 
date with various gotchas we learned while doing the KSA implementation.

> Thanks,
> 
> Steve
> 
> [1] http://specs.openstack.org/openstack/api-wg/guidelines/consuming-catalog.html
> [2] https://www.openstack.org/marketplace/distros/distribution/red-hat/red-hat-openstack-platform
> 
> _______________________________________________
> Openstack-api-consumers mailing list
> Openstack-api-consumers at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-api-consumers
> 




More information about the Openstack-api-consumers mailing list