Re: [openstack-dev] Endpoint structure: a free-for-all

2016-10-21 Thread Doug Hellmann
> On Oct 21, 2016, at 7:22 AM, Chris Dent wrote: > >> On Wed, 19 Oct 2016, Sean Dague wrote: >> >> The reason we have volume, volumev2, and volumev3 is that no one actually >> wants the unversioned volume endpoint. You can't do anything with it. >> Everyone wants the

Re: [openstack-dev] Endpoint structure: a free-for-all

2016-10-21 Thread Chris Dent
On Wed, 19 Oct 2016, Sean Dague wrote: The reason we have volume, volumev2, and volumev3 is that no one actually wants the unversioned volume endpoint. You can't do anything with it. Everyone wants the actual endpoint that has resources. That's right, they do want the endpoint that has the

Re: [openstack-dev] Endpoint structure: a free-for-all

2016-10-20 Thread joehuang
Hi, I recalled one issue during using endpoint structure in public cloud based on OpenStack. Currently each service listens on its own port, the format of the endpoint is like: service-specific ports, e.g., https://cloud.com:1234/v2 If the end user want to access Nova/Cinder/Neutron service

Re: [openstack-dev] Endpoint structure: a free-for-all

2016-10-20 Thread Matt Riedemann
On 10/20/2016 2:10 AM, Qiming Teng wrote: I know some services "hide" this version endpoint behind authentication middleware (or somthing similar). In other words, you have to authenticate to keystone before you can get the version info. Can we please standardize that? I've noticed that as

Re: [openstack-dev] Endpoint structure: a free-for-all

2016-10-20 Thread Sean Dague
On 10/20/2016 06:09 AM, Thierry Carrez wrote: Sean Dague wrote: [...] At 5 services, maybe. But at 50+ services (and growing) I think that the idea of get an endpoint, then have custom parsing code for every service because their version documents are different, is a really bad UX. [...] Bit

Re: [openstack-dev] Endpoint structure: a free-for-all

2016-10-20 Thread Thierry Carrez
Sean Dague wrote: > [...] > At 5 services, maybe. But at 50+ services (and growing) I think that the > idea of get an endpoint, then have custom parsing code for every service > because their version documents are different, is a really bad UX. > [...] Bit of a digression, but I'm curious where

Re: [openstack-dev] Endpoint structure: a free-for-all

2016-10-20 Thread Qiming Teng
On Thu, Oct 20, 2016 at 02:01:07AM -0500, Monty Taylor wrote: > On 10/19/2016 12:07 PM, Matt Riedemann wrote: > > On 10/19/2016 10:32 AM, Brian Curtin wrote: > >> I'm currently facing what looks more and more like an impossible > >> problem in determining the root of each service on a given cloud.

Re: [openstack-dev] Endpoint structure: a free-for-all

2016-10-20 Thread Monty Taylor
On 10/19/2016 12:07 PM, Matt Riedemann wrote: > On 10/19/2016 10:32 AM, Brian Curtin wrote: >> I'm currently facing what looks more and more like an impossible >> problem in determining the root of each service on a given cloud. It >> is apparently a free-for-all in how endpoints can be

Re: [openstack-dev] Endpoint structure: a free-for-all

2016-10-19 Thread Sean Dague
On 10/19/2016 04:22 PM, Matt Riedemann wrote: I personally thought long-term we wanted unversioned endpoints in the service catalog, and if you want to do version discovery, you do a GET on a particular service's endpoint URL in the service catalog, and that returns the list of available API

Re: [openstack-dev] Endpoint structure: a free-for-all

2016-10-19 Thread Brant Knudson
On Wed, Oct 19, 2016 at 2:27 PM, Brian Curtin wrote: ... > > This started back in August when it came up that we didn't know where > that Keystone v3 endpoint was. After talking with a few people, Steve > Martinelli mentioned that at least as of then, hitting the unversioned >

Re: [openstack-dev] Endpoint structure: a free-for-all

2016-10-19 Thread Matt Riedemann
On 10/19/2016 3:22 PM, Matt Riedemann wrote: On 10/19/2016 2:27 PM, Brian Curtin wrote: On Wed, Oct 19, 2016 at 2:03 PM, Sean Dague wrote: On 10/19/2016 01:40 PM, Brian Curtin wrote: On Wed, Oct 19, 2016 at 12:59 PM, Jay Pipes wrote: On 10/19/2016 05:32

Re: [openstack-dev] Endpoint structure: a free-for-all

2016-10-19 Thread Matt Riedemann
On 10/19/2016 2:27 PM, Brian Curtin wrote: On Wed, Oct 19, 2016 at 2:03 PM, Sean Dague wrote: On 10/19/2016 01:40 PM, Brian Curtin wrote: On Wed, Oct 19, 2016 at 12:59 PM, Jay Pipes wrote: On 10/19/2016 05:32 PM, Brian Curtin wrote: I'm currently facing

Re: [openstack-dev] Endpoint structure: a free-for-all

2016-10-19 Thread Brian Curtin
On Wed, Oct 19, 2016 at 2:03 PM, Sean Dague wrote: > On 10/19/2016 01:40 PM, Brian Curtin wrote: >> On Wed, Oct 19, 2016 at 12:59 PM, Jay Pipes wrote: >>> On 10/19/2016 05:32 PM, Brian Curtin wrote: I'm currently facing what looks more and more like

Re: [openstack-dev] Endpoint structure: a free-for-all

2016-10-19 Thread Sean Dague
On 10/19/2016 01:40 PM, Brian Curtin wrote: > On Wed, Oct 19, 2016 at 12:59 PM, Jay Pipes wrote: >> On 10/19/2016 05:32 PM, Brian Curtin wrote: >>> >>> I'm currently facing what looks more and more like an impossible >>> problem in determining the root of each service on a

Re: [openstack-dev] Endpoint structure: a free-for-all

2016-10-19 Thread Brian Curtin
On Wed, Oct 19, 2016 at 12:59 PM, Jay Pipes wrote: > On 10/19/2016 05:32 PM, Brian Curtin wrote: >> >> I'm currently facing what looks more and more like an impossible >> problem in determining the root of each service on a given cloud. It >> is apparently a free-for-all in

Re: [openstack-dev] Endpoint structure: a free-for-all

2016-10-19 Thread Matt Riedemann
On 10/19/2016 10:32 AM, Brian Curtin wrote: I'm currently facing what looks more and more like an impossible problem in determining the root of each service on a given cloud. It is apparently a free-for-all in how endpoints can be structured, and I think we're out of ways to approach it that

Re: [openstack-dev] Endpoint structure: a free-for-all

2016-10-19 Thread Jay Pipes
On 10/19/2016 05:32 PM, Brian Curtin wrote: I'm currently facing what looks more and more like an impossible problem in determining the root of each service on a given cloud. It is apparently a free-for-all in how endpoints can be structured, and I think we're out of ways to approach it that