<div dir="ltr"><div><div><div>Hi Monty,<br><br></div>Would you be able to provide links to the os-client-config patch(es) that add this support? I might be able to use it as a guideline for Gophercloud.<br><br></div>Thanks,<br></div>Joe<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 19, 2017 at 1:44 PM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 07/20/2017 03:32 AM, Steve Gordon wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi folks,<br>
<br>
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).<br>
</blockquote>
<br></span>
WELL ...<br>
<br>
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.<br>
<br>
This includes discovering what versions are available as well as what microversion ranges each service supports.<span class=""><br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br>
</blockquote>
<br></span>
Exactly.<br>
<br>
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"<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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).<br>
</blockquote>
<br></span>
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:<br>
<br>
<a href="https://review.openstack.org/#/c/459869/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/459869/</a><br>
<br>
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.<br>
<br>
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)<br>
<br>
<a href="https://review.openstack.org/#/q/topic:version-discovery" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/q/topic:version-discovery</a><br>
<br>
contains the giant pile of patches associate with this.<br>
<br>
You also probably want to get up to speed on these:<br>
<br>
<a href="https://review.openstack.org/#/c/459405/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/459405/</a><br>
<a href="http://specs.openstack.org/openstack/api-wg/guidelines/consuming-catalog.html" rel="noreferrer" target="_blank">http://specs.openstack.org/ope<wbr>nstack/api-wg/guidelines/consu<wbr>ming-catalog.html</a><br>
<a href="https://service-types.openstack.org/" rel="noreferrer" target="_blank">https://service-types.openstac<wbr>k.org/</a><br>
<br>
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.<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks,<br>
<br>
Steve<br>
<br>
[1] <a href="http://specs.openstack.org/openstack/api-wg/guidelines/consuming-catalog.html" rel="noreferrer" target="_blank">http://specs.openstack.org/ope<wbr>nstack/api-wg/guidelines/consu<wbr>ming-catalog.html</a><br>
[2] <a href="https://www.openstack.org/marketplace/distros/distribution/red-hat/red-hat-openstack-platform" rel="noreferrer" target="_blank">https://www.openstack.org/mark<wbr>etplace/distros/distribution/<wbr>red-hat/red-hat-openstack-<wbr>platform</a><br>
<br>
______________________________<wbr>_________________<br>
Openstack-api-consumers mailing list<br>
<a href="mailto:Openstack-api-consumers@lists.openstack.org" target="_blank">Openstack-api-consumers@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-api-consumers" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-api-consumers</a><br>
<br>
</blockquote>
<br>
<br>
______________________________<wbr>_________________<br>
Openstack-api-consumers mailing list<br>
<a href="mailto:Openstack-api-consumers@lists.openstack.org" target="_blank">Openstack-api-consumers@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-api-consumers" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-api-consumers</a><br>
</div></div></blockquote></div><br></div>