Open Stack

+1

I Agree.


----- Original Message -----
> From: "Tal Kammer" <tkammer at redhat.com>
> To: "All Things QA." <openstack-qa at lists.openstack.org>
> Sent: Monday, June 10, 2013 3:18:32 PM
> Subject: Re: [openstack-qa] Data encapsulation within Tempest
> 
> 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
> 
> _______________________________________________
> openstack-qa mailing list
> openstack-qa at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa
>