[openstack-dev] [api] [devstack] [ocata] Consistent Endpoint Discovery

Michael Krotscheck krotscheck at gmail.com
Fri Sep 9 15:50:49 UTC 2016


Hey there, Goutham, thanks for replying!

I don't dispute that the services are properly returning a list of
supported versions, if you request the root resource. So far, that works
wonderfully.

I'm speaking of the resource endpoint that an API client is given when it
queries the keystone service catalog. We have a dump of the devstack output
in our testing data here ->
http://git.openstack.org/cgit/openstack/js-openstack-lib/tree/test/unit/helpers/data/keystone.js#n392

As you can see, some services give us tenant ID, some give us version, some
give us the root resource - and there's no indication of why that is. Is it
fragile? Would removing the version from the nova URI in the catalog entry
itself cause other services to fail? One would think not, but if that's the
case why are the versions declared explicitly in the first place?

Michael Krotscheck

On Thu, Sep 8, 2016 at 10:15 AM Ravi, Goutham <Goutham.Ravi at netapp.com>
wrote:

> Hi Michael,
>
>
>
> We discussed this at the API-WG meeting today (occurs at 16:00 UTC on
> Thursdays, #openstack-meeting-3). A point regarding the ‘/’ endpoint and
> the versions response is made in the microversions guideline [1]
> <https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html#version-discovery>.
> I was testing the services you mentioned (+ manila), the results from my
> environment are here [2]. <http://paste.openstack.org/show/569282/> Looks
> like none of the services require authentication to make a request to the
> bare endpoint. What am I missing? One thing to note is that you included
> the tenant ID and /v3 in case of cinder; why is that?
>
>
>
> When instantiating a client and performing version negotiation, you may
> have auth details; but looks like we have some consistency among all of the
> projects you mentioned to not require auth. Maybe we can add this to [1].
>
>
>
> Thanks,
>
> Goutham
>
>
>
> [1]
> https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html#version-discovery
>
> [2] http://paste.openstack.org/show/569282/
>
>
>
>
>
> *From: *Michael Krotscheck <krotscheck at gmail.com>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev at lists.openstack.org>
> *Date: *Tuesday, August 30, 2016 at 1:11 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> *Subject: *[openstack-dev] [api] [devstack] [ocata] Consistent Endpoint
> Discovery
>
>
>
> Hey everyone - I have a little bit of a UX request for our API developers.
>
>
>
> For the last week or so, I've been working on building version negotiation
> logic for an OpenStack SDK. The process is pretty simple:
>
>
>
> 1- Read clouds.yaml for the keystone URL.
>
> 2- Query keystone for the service catalog.
>
> 3- Instantiate service instances for each discovered service.
>
> 4- Perform version negotiation on each service.
>
>
>
> The problem: the service endpoints registered in the catalog all behave
> just a little bit differently, which makes building consistent version
> negotiation a royal PITA. I've annotated the various behaviors from a
> default devstack configuration here:
> http://paste.openstack.org/show/564863/.
>
>
>
> In a perfect world, every endpoint would return the same type of resource
> - most likely the versions resource as described in the API WG
> Microversions spec. It would also be nice if version negotiation can happen
> without requiring authentication, the easiest path to which would be
> supporting the 'max_version' and 'min_version' fields in the root versions
> resource.
>
>
>
> Sadly, this is my last week before I'm no longer paid to contribute to the
> OpenStack community, so I can't take on the responsibility of proposing
> something of this magnitude as an Ocata goal with only my own free time to
> offer. Is there anyone willing to help push this forward?
>
>
>
> Michael
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160909/a8315236/attachment.html>


More information about the OpenStack-dev mailing list