Open Stack

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?

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

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.

Regards,
Tal

----- Original Message -----
From: "Sean Dague" <sean at dague.net>
To: "All Things QA." <openstack-qa at lists.openstack.org>
Sent: Monday, June 10, 2013 3:48:35 PM
Subject: Re: [openstack-qa] Data encapsulation within Tempest

On 06/09/2013 05:54 PM, Daryl Walleck wrote:
>>> Why do we need so many "if" statements for username/password/tenant/etc in the Manager class? or a >>better question is "why is the Manager class dependent on a specific implementation of an Identity >>component" (keystone)?
>
>> I don't really think we need a Manager class at all. It serves no purpose, IMO.
>
> In its current form the manager class is extremely verbose. However, I think there is some value in having a single entry point into the clients. There are better ways to do this dynamically that involve far less code.
>
>>> In the "services" folder.
>>> Why do we need two clients for JSON/XML?
>
>> Because both code paths need testing?
>
> It's very possible to get rid of the duplicate clients by extracting the one thing that varies (serialization/deserialization) from the clients and handle it elsewhere. This allowed us to greatly reduce the amount of duplicated client code we have in CloudCafe.

Realistically, Tempest is close to that model today anyway, all the best 
REST handling happens in common. It could be made cleaner, for sure, but 
I'd be surprised if you dropped all that much code in the process.

	-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