Open Stack

Hi Monty,

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.

Thanks,
Joe

On Wed, Jul 19, 2017 at 1:44 PM, Monty Taylor <mordred at inaugust.com> wrote:

> 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/consu
> ming-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/consu
>> ming-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/openstac
>> k-api-consumers
>>
>>
>
> _______________________________________________
> Openstack-api-consumers mailing list
> Openstack-api-consumers at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k-api-consumers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-api-consumers/attachments/20170721/5d15c66c/attachment.html>