Open Stack

Hi Ali! Some questions and commentary inline...

On 01/29/2013 01:14 PM, Ali, Haneef wrote:
> 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"
>  }

What would xxx and yyy be? why would you have two endpoints with the
same name? Why would endpoints even have a name? The endpoint's
identifier is merely the URI, no?

or am I missing something obvious here? Very well could be :)

> 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?

It actually doesn't make much sense IMO to assume the client is
keystoneclient. The reason is because you don't use keystoneclient to do
things related to compute. So the keystoneclient would not be "sending a
request to https://compute.com/yyy ... to retrieve the version".
Instead, the compute client would be doing that. And it would be up to
the compute client to follow the URI of the endpoint of type "compute"
in the region and AZ the client wants and request the root URI of that
endpoint. The root URI should return a 300 Multiple Choice with the list
of supported Compute API versions of that compute endpoint and the
client should cache that information.

I don't see (m)any valid reasons to have multiple compute API endpoints
per availability zone in a region. If you have multiple compute API
endpoints in an availability zone because you have some HA setup, then
you should be spreading the load to those multiple compute API nodes
using a load-balancer, no? Not relying on the client to pick and choose
which of X compute API nodes in an availability zone to hit...

>Is the keystone-client expected to know the response format? Do you
expect the version information returned by "swift" same as that of "compute"

Good question. It would be awesome if OpenStack projects that publish a
public API would standardize on the results returned by a call to the
API endpoint's root URI (the one that should return a 300 Multiple
Choice with the version information).

Best,
-jay


> -----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
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>