Re: [openstack-dev] [api] [devstack] [ocata] Consistent Endpoint Discovery
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.r...@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 <krotsch...@gmail.com> > *Reply-To: *"OpenStack Development Mailing List (not for usage > questions)" <openstack-dev@lists.openstack.org> > *Date: *Tuesday, August 30, 2016 at 1:11 PM > *To: *"OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] [devstack] [ocata] Consistent Endpoint Discovery
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 <krotsch...@gmail.com> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: Tuesday, August 30, 2016 at 1:11 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
