Open Stack

On 06/11/2013 05:01 PM, Attila Fazekas wrote:
>
>
>
>
> ----- Original Message -----
>> From: "Sean Dague" <sean at dague.net>
>> To: openstack-qa at lists.openstack.org
>> Sent: Monday, June 10, 2013 4:09:40 PM
>> Subject: Re: [openstack-qa] Data encapsulation within Tempest
>>
>> On 06/10/2013 09:18 AM, Tal Kammer wrote:
>>> I fail to see how is it close to that model today.
>>>
>>> We have a lot of duplicate code in pretty much every implementation of XML
>>> vs JSON..
>>> what will happen if tomorrow we move to SOAP? do we really want to build a
>>> new client for every single component? (as it is now..)
>>   >
>>> if we look at the rest_client module as it is today, let's take the
>>> "identity_auth_v3" for example, what happens when a auth_v4 comes out? v5?
>>> do we just keep adding layers?
>>
>> Identity v4 would presumably be different enough from identity v3, that
>> there would probably not be a huge amount of code reuse. Nova v2 -> v3
>> is a little bit breaking with this model.
>>
>>> Having a model of a "Request" object (or any other name/object, the
>>> implementation itself is not relevant for the argument) immediately
>>> removes all duplication in clients (which is a lot of code), and a lot
>>> more code if we consider add ons in the future. (and I do believe we
>>> should consider the future..)
>>>
>>> Also, all response handling is hard coded, why not separate it into a
>>> class/module of it's own?
>>> Currently, if devs decide to change the response code, there is no graceful
>>> way of handling it. everything will pretty much fail..
>>
>> Currently if devs decide to change the response code that's an API
>> violation, and should be stopped. So optimizing for that use case really
>> isn't the best idea.
>>
> AFAIK the guideline just contains restrictions against the 2xx type change.
> https://wiki.openstack.org/wiki/APIChangeGuidelines#Generally_Considered_OK
>
> Many status code does not used properly at the moment, not juts because using
> the WebDav's status codes is a gray area.

It's not a gray area.

> There are situations where the 4xx error codes should be changed to 5xx.
> I mean If the service is miss-configured or a dependent component down,
> it is not client's (4xx) fault.
>
> In some not yet tested situation, we might see 2xx code instead of 4xx,
> IMHO they should be fixed.

The guidelines don't tell the whole story. As a Nova core reviewer we've 
been trying to prevent random error code changing as well, and it was 
part of the whole point of v3 API transition.

Stable APIs are critical to API adoption. It's much more important that 
a kind of failure today fails the same way tomorrow than it becomes 
semantically correct by someone's current interpretation of HTTP. :)

We have version bumps on the API for a reason. Just because we've been 
completely terrible documenting the API surface doesn't give people the 
free hand to randomly change error codes.

Honestly though, this has turned into a completely useless theoretical 
discussion, where I don't think anything has come out of it except burnt 
time. It would be better if we used this kind of energy on things like 
our high priority blueprints - https://blueprints.launchpad.net/tempest

Like, for instance, getting testr into the mix, which we've been talking 
about as a team for the last 6 months. Matt's working on it now, but it 
could definitely use more hands, eyes, etc.

	-Sean

-- 
Sean Dague
http://dague.net