[openstack-qa] Data encapsulation within Tempest
daryl.walleck at RACKSPACE.COM
Sun Jun 9 21:54:53 UTC 2013
>> 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.
From: Jay Pipes [mailto:jaypipes at gmail.com]
Sent: Sunday, June 9, 2013 2:50 PM
To: openstack-qa at lists.openstack.org
Subject: Re: [openstack-qa] Data encapsulation within Tempest
On 06/09/2013 10:50 AM, Tal Kammer wrote:
> 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?
No idea. I can't stand this aspect of it.
> In the "clients.py" file.
> Why do we need an "AdminManager"/"AltManager"/"ComputeAdminManager"?
See previous email with code from my proof of concept. Instead of using admin manager, alt manager, and all that stuff, it uses role-based user management, which is a much cleaner strategy than the current one, IMO.
> 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 the "services" folder.
> Why do we need two clients for JSON/XML?
Because both code paths need testing?
> 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.
I don't believe we need a Manager class at all. We should use the fixtures.Fixture class as our basic unit of test-needed resources and use fixtures.TestWithFixtures to handle much of the plumbing.
> 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 :)
> Tal Kammer
> (tkammer on IRC)
> openstack-qa mailing list
> openstack-qa at lists.openstack.org
openstack-qa mailing list
openstack-qa at lists.openstack.org
More information about the openstack-qa