Open Stack

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

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.

> > If we agree that things can be cleaner, why not start the cleaning process?
> > If it's a matter of time, I am more than willing to volunteer.
> 
> I have no issues with cleanups. :) I'll happily review them.
> 
> I think the best place to go from here is some sample of what it would
> look like that could be concrete. Start with one of the smaller clients
> and work out from there.
> 
> I also really think this work needs to dovetail in getting us over to
> fixtures for testr. Jay already started with some ideas there, Matt's
> trying to drive some examples on the images clients.
> 
> I'm all for a more compact and cleaner code base to encourage additional
> development.
> 
> 	-Sean
> 
> --
> Sean Dague
> http://dague.net
> 
> _______________________________________________
> openstack-qa mailing list
> openstack-qa at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa
>