Open Stack

>> 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.

Daryl

-----Original Message-----
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:
<snip>
> 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.

Best,
-jay

> 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
>


_______________________________________________
openstack-qa mailing list
openstack-qa at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa