[openstack-qa] Data encapsulation within Tempest

Attila Fazekas afazekas at redhat.com
Tue Jun 11 21:01:11 UTC 2013

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

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

More information about the openstack-qa mailing list