Open Stack

I do understand your argument, but like to understand how can  the client interpret it?


GET /endpoints/type=openstack-compute

 [
 {
   "region": "north",
   "name": "zone1",
   "facing": "public:
   "uri": "https://compute.com/xxx
 }
{
   "region": "north",
   "name": "zone1",
   "facing": "public:
   "uri": "https://compute.com/yyy"
 }


Assume the client is keystone-client.  How is it going to interpret it? It got 2 public endpoints.  If the keystone-client is going to send the request to "https://compute.com/yyy" & "https://compute.com/zzz"  to retrieve the version, what is the expected response format?  Is the keystone-client expected to know the response format?  Do you expect the version information returned by "swift" same as that of "compute"


Thanks
Haneef
 
-----Original Message-----
From: Jay Pipes [mailto:jaypipes at gmail.com] 
Sent: Tuesday, January 29, 2013 9:21 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [keystone] endpoint versioning in API v3

On 01/29/2013 12:07 PM, Ali, Haneef wrote:
> Hi,
> 
> Assuming a deployment already has compute v2, and they want to introduce compute v3. Both compute v2 and v3 is going be live for some time.  In that case, how does the response for  GET /services and GET /endpoints look?  

As below. I'm saying that the source of truth for what versions of an
API an endpoint exposes is the endpoint itself, not Keystone.

So Keystone would merely expose the existence of the endpoint, and the
endpoint itself would be queried for the versions it supports.

Best,
jay

> -----Original Message-----
> From: Jay Pipes [mailto:jaypipes at gmail.com] 
> Sent: Tuesday, January 29, 2013 7:37 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [keystone] endpoint versioning in API v3
> 
> On 01/28/2013 03:21 PM, Dolph Mathews wrote:
>> I just noticed that we overlooked/forgot a feature from the v2
>> serviceCatalog API which includes the following attributes on each endpoint:
>>
>>   "versionId": "1.0",
>>   "versionList": "https://compute.north.host/",
>>   "versionInfo": "https://compute.north.host/v1.0/",
>>
>> I never completely understood the intended use case for these
>> attributes... e.g. if you can ask the remote service for a 'version
>> list' then why does keystone need to redundantly identify the API
>> version of the endpoint and enumerate options for each API version? I
>> don't think you should have to revise your service catalog to roll out a
>> new API version, either. IMO, clients should (ideally) start with an
>> unversioned endpoint, receive a 300 Multiple Choice response, and select
>> a compatible/acceptable versioned endpoint before proceeding.
>>
>> Is anyone using this feature in v2 and want to see it carried forward to v3?
> 
> I think versionList is pointless, as you mention above the proper way of
> handling this is a 300 Multiple Choice response on the base endpoint.
> The endpoints themselves should be the source of truth about what
> versions of an API they expose or support. Keystone, IMHO, should merely
> be a directory of endpoints/services, not a directory of endpoints and
> API versions on an endpoint.
> 
> So, I'd prefer very much to see Keystone just return, for example:
> 
> GET /services
> [
> {
>   "type": "openstack.compute",
>   "region": "north",
>   "uri": "https://compute.north.host.com"
> },
> {
>   "type": "openstack.image",
>   "region": "north",
>   "uri": "https://image.north.host.com"
> },
> {
>   "type": "openstack.volume",
>   "region": "north",
>   "uri": "https://volume.north.host.com"
> },
> {
>   "type": "ec2.compute",
>   "region": "north",
>   "uri": "https://ec2.north.host.com"
> }
> ]
> 
> and then have the requesting client query and cache the result of a call
> to the service endpoint's base URI, which would return the 300 Multiple
> Choice with a version information dictionary particular to that endpoint.
> 
> That way you keep the source of truth about the endpoint's exposed API
> versions where it belongs: in the endpoint that publishes the API.
> 
> Also, I re-iterate it would be awesome to be able to do the following in
> Keystone:
> 
> GET https://auth.host.com/regions
> [
> {
>   "name": "north",
>   "uri": "https://auth.north.host.com"
> }.
> {
>   "name": "south",
>   "uri": "https://auth.south.host.com"
> }
> ]
> 
> as well as:
> 
> GET https://auth.host.com/availability-zones
> [
> {
>   "region": "north",
>   "name": "zone1",
>   "uri": "https://auth.zone1.north.host.com"
> }.
> {
>   "region": "north",
>   "name": "zone2",
>   "uri": "https://auth.zone2.north.host.com"
> },
> {
>   "region": "south",
>   "name": "zone1",
>   "uri": "https://auth.zone1.south.host.com"
> }.
> {
>   "region": "south",
>   "name": "zone2",
>   "uri": "https://auth.zone2.south.host.com"
> }
> ]
> 
> With requests to a an individual region's Keystone service returning
> only the availability zones in that region:
> 
> GET https://auth.north.host.com/availability-zones
> [
> {
>   "region": "north",
>   "name": "zone1",
>   "uri": "https://auth.zone1.north.host.com"
> }.
> {
>   "region": "north",
>   "name": "zone2",
>   "uri": "https://auth.zone2.north.host.com"
> }
> ]
> 
> This way we would be able to structure deployments in a way that would
> enable clients to find global information about the regions in a
> deployment as well as finer-grained drill-down information about
> endpoints in a specific region or availability zone by simply following
> the URIs.
> 
> Best,
> -jay
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev