Open Stack

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