Open Stack

----- Original Message -----
> From: "Daryl Walleck" <daryl.walleck at RACKSPACE.COM>
> To: "All Things QA." <openstack-qa at lists.openstack.org>
> Sent: Sunday, June 9, 2013 11:54:53 PM
> Subject: Re: [openstack-qa] Data encapsulation within Tempest
> 
> >> 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.
> 

Less code generally more readable.

The only additional thing we need to consider, how many places we need to modify
code in order to add new functionality.

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

Agreed.

The request generations in all OpenStack per HTTP method type is very similar.
We just need several smart functions.
 
> 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
> 
> _______________________________________________
> openstack-qa mailing list
> openstack-qa at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa
>