[openstack-qa] Data encapsulation within Tempest

Jay Pipes jaypipes at gmail.com
Sun Jun 9 19:44:46 UTC 2013


On 06/09/2013 10:50 AM, Tal Kammer wrote:
> Hi all,
>
> Per our discussion on Thursday's meeting, I would like to propose that as part of the new design/restructure of Tempest, we would also try and encapsulate data and/or separate duties of certain classes.
> I have written a blueprint that I believe can be a good first step towards that goal, but I wanted first to "throw" the idea here for discussion and hear your thoughts on the matter.
>
> I would like everyone to go over the following blueprint just to get the general Idea of what I'm proposing:
> https://wiki.openstack.org/wiki/Blueprint-EncapsulatingData
>
> I believe there are currently three major places that this approach can prove useful:
>
> 1. User management (as described in the blueprint)

What you are describing (partly) in your blueprint are fixture objects. 
I fully support this approach, and I even put a proof of concept 
together back in January that handled user and tenant management using 
fixtures:

https://github.com/jaypipes/tempest/blob/api/tempest/fixtures/identity.py

Note that it uses the fixtures library [1] from Robert Collins (lifeless 
on IRC) and the code uses the python-keystoneclient library directly 
instead of the Tempest clients.

The base test case in the proof-of-concept code inherits from 
testtools.TestCase and fixtures.TestWithFixtures. This adds to the base 
test class the addFixture() method, which ensures that any fixtures are 
automatically cleaned up when tearDown is called.

Perhaps you might take a look at the code and see if it would be useful.

Best,
-jay

[1] https://pypi.python.org/pypi/fixtures
[2] 
https://github.com/jaypipes/tempest/blob/api/tempest/tests/api/base.py#L44

> 2. Plug-ability / Future enhancement
> 3. Readability - by encapsulating the data into dedicated objects we help people understand the system and "what comes from where".
>
> Some code examples:
> In the "base.py" file in the identity section.
> Why does the BaseIdentityAdminTest class needs to hold so many clients inside it?
>
> In the "clients.py" file.
> Why do we need an "AdminManager"/"AltManager"/"ComputeAdminManager"?
> 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)?
>
> In the "services" folder.
> Why do we need two clients for JSON/XML?
>
> I believe that all the examples above can easily be improved by encapsulation and separation of duties.
> for example, in the "clients.py":
> If we create an object named "User" (or a KeystoneUser) that will hold the proper credentials and send it to the Manager class directly, or better yet, to a KeystoneManager (that inherit/composite Manager) that knows what are the requirements for a keystone authentication, we simplified the way of using our code and consolidate five different classes into one.
>
> There are more examples of how encapsulation and separation of duties can help us down size the amount of code we write and help us be modular, but I will stop here as this mail got pretty long as it is :)
>
> Thoughts?
>
> Tal Kammer
> (tkammer on IRC)
>
> _______________________________________________
> 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