Open Stack

Keystone should follow what nova, cinder, and glance are doing, with version 3.  Here's a thought, we can set a slightly different mimetype in the Accept header to get the new format, so you don't break old clients.  If you just set application/json for example, you'd get the old format.  If you set accept to something like application/vnd.openstack.versions+json you get the new format.  Have nova, cinder, and glance recognize the mimetype as well.

-jOrGe W.

On Jan 29, 2013, at 5:58 PM, Dean Troyer wrote:

> On Tue, Jan 29, 2013 at 1:48 PM, Jay Pipes <jaypipes at gmail.com> wrote:
>>> 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).
> 
> Keystone appears to be the outlier here, nova, cinder and glance all
> return a list of version structures like:
> 
> { "versions": [ { ... }, ] }
> 
> where keystone's looks like:
> 
> { "versions": { "values": [ { ... }, ] } }
> 
> I'm trying to think of a way to change that without breaking things.
> How do we version the version discovery API?   It's trivial to change
> keystoneclient, but that still breaks all of the other language
> bindings that actually use it.
> 
> Swift returns a 404.  I didn't have an operational Quantum API
> available to check it.
> 
> dt
> 
> -- 
> 
> Dean Troyer
> dtroyer at gmail.com
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev