Open Stack

On 07/26/2012 10:25 AM, David Kranz wrote:
> On 7/26/2012 10:00 AM, Adam Young wrote:
>> The discussion on the dev list about David Kranz's proposal for 
>> avoiding breakages: http://etherpad.openstack.org/Hn8rKP7XgB got me 
>> thinking about the changes that have gone in recently into Keystone. 
>> Specifically,  we have changed a bunch of return codes amongs the 
>> various 400 series depending on the current thinking if something 
>> should be "Unauthorized" versus "Forbidden".  This will probably mess 
>> someone up.
>>
>> At the level of service.py or any of the other Python objects that 
>> actually return error codes, they do not have a way to check the API 
>> version.  When the time comes to implement V3.0, we are going to 
>> need  a better mechanism to distinguish between the V2 and V3 code 
>> paths.  Has any thought gone into this?  Are we going to support V2 
>> and V3 in the same code base?
>>
>> It might be worthwhile to bump the minor version number for the 
>> Keystone API for Folsom,  to indicate that the V2 contract is not 
>> supported: V2.1.
>
> I may be missing something but I think a minor version bump indicates 
> that the original version *is* supported. I added to the etherpad a 
> suggestion that there be an API  to query an endpoint for the minor 
> version number it supports. That would give clients a way to know if 
> functions that were compatibly added in a new minor version are 
> available.

Well,  the idea is that by bumping the minor version,  we are indicating 
that, while the intention is to support V2,  we admit we might have 
broken it.  Right now, all we know is when we break the unit tests, we 
fix them, and that is obviously not a great approach.

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