Open Stack

----- Original Message -----
> From: "Jay Pipes" <jaypipes at gmail.com>
> To: openstack-qa at lists.openstack.org
> Sent: Sunday, June 9, 2013 9:50:05 PM
> 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.

Tempest has 4-5 incomplete missuses concept about managers right now.
We have more base classes than we actually need.

The simplest concept what we are close to is have a tool chain
 (clients to access openstack) behalf on a user.

- We have 3-4 predefined user at the moment.
- We do not need to cleanup tokens 

The test cases which testing role based access, might need to create new users,
 and they need to act as an user.

This privilege and capability, just required 
 in small portions of the test cases and test types.

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