[openstack-qa] Data encapsulation within Tempest
afazekas at redhat.com
Tue Jun 11 15:22:51 UTC 2013
The tempest rest clients contains too many logic.
They does not need to do authentication or waiting by himself.
The clients can get just a token in a simple model.
In more advanced model, they can get a token provider
(closure function, or class), which ensures about giving valid token,
and it can cache the token properly.
----- Original Message -----
> From: "Sean Dague" <sean at dague.net>
> To: "All Things QA." <openstack-qa at lists.openstack.org>
> Sent: Monday, June 10, 2013 2: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 Dague
> openstack-qa mailing list
> openstack-qa at lists.openstack.org
More information about the openstack-qa