[openstack-qa] On refactoring of base classes/infrastructure

Attila Fazekas afazekas at redhat.com
Thu Feb 21 16:52:03 UTC 2013



----- Original Message -----
> From: "Jay Pipes" <jaypipes at gmail.com>
> To: openstack-qa at lists.openstack.org
> Sent: Thursday, February 21, 2013 4:22:21 PM
> Subject: Re: [openstack-qa] On refactoring of base classes/infrastructure
> 
> On 02/20/2013 11:03 PM, Daryl Walleck wrote:
> > There's been a lot of interest around modifying the base test
> > classes in
> > Tempest, which is something that without a doubt needs to be
> > explored.
> > Before doing that, I'd like to make sure we're thinking of what the
> > problem we're trying to solve is by doing this and what the final
> > solution should look like. I think we can all agree on these
> > things:
> > 
> >   * We need something to prepare test configuration
> >   * Something to manage resources generated from tests
> >   * A means to load all necessary clients for testing
> 
> Yep, agreed.
> 
> > Where I started to get concerned was when I noticed the number of
> > classes we needed to inherit from just to enable basic
> > functionality.
> > Going through the class model again brought up some other
> > difficulties:
> > 
> >   * The openstack module has grown to the point of being unwieldy
> 
> Agreed.
> 
> >   * We load every client for every test regardless of the product
> 
> Actually, it's not that we load every client that bothers me. It's
> that
> we break clients out unnecessarily to begin with. I would vastly
> prefer
> to have a single file for compute JSON client and a single file for
> compute XML client (per major version of course). Having dozens of
> these
> little clients is silly, IMHO.

Probably we can came up with a solution, to move both xml and json clients to the same file (per remote service) and still keep it small.
We should use the rest API's key naming in our code even, even if it would violate, the python variable naming conventions.  

The rest_clients /service proxies/ does lazy authentication, so if they not used, they does not have significant cost.
We are now creating "demo" users too frequently, probably we just need to create users just per process, and we just had get a token (excluding keystone test) only once  (unless it expires, but usually they have 24h lifetime).
The current behavior spend measurable additional unnecessary time in chatting with keystone.  

> >   * It's not necessarily clear what belongs in each level of base
> >   test class
> > 
> > It seems like we could handle some of our complexity through
> > aggregates
> > and breaking things down into smaller pieces. I also think base
> > test
> > classes might not be the right term in some cases, as they're
> > really
> > more of high level fixtures. Just my thoughts, but here's what I
> > sketched out.
> > 
> > http://imgur.com/fqD01OT
> 
> Other than the split out of multiple client files/classes, I think
> this
> is good. It looks virtually identical to the proof of concept I put
> together that uses the fixtures.Fixture and
> testresources.ResourceTestCase classes as bases:
> 
> https://github.com/jaypipes/tempest/blob/api/tempest/fixtures/identity.py
> https://github.com/jaypipes/tempest/blob/api/tempest/tests/api/base.py
> 
> with this test case showcasing the approach:
> 
> https://github.com/jaypipes/tempest/blob/api/tempest/tests/api/compute/test_flavors.py
> 
> Best,
> -jay
> 
> _______________________________________________
> openstack-qa mailing list
> openstack-qa at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa
> 

There is lot of code duplication and other anomalies in our base test classes.
First, we should have 4 more generic base classes 
- One for both XML/JSON
- One for pythton-client libs
- One for AWS/Boto
- One for CLI

Both of them, should cover all functionality regardless to the remote service type. 

Slowly we should make them more similar to each other....

Most of the whitebox features, should go to some utils like place.




More information about the openstack-qa mailing list