[openstack-qa] On refactoring of base classes/infrastructure

Daryl Walleck daryl.walleck at RACKSPACE.COM
Thu Feb 21 21:28:01 UTC 2013


If you're referring to the command line client code that I proposed this morning, that was an effort in good faith to follow through with Sam's promise from last week for a quick turn around effort to get code to look at. I literally ripped it from its prototype form (from a project that had nothing to do with Tempest) and put it out exactly as is to see if the infrastructure would be useable somehow. I realize it was not pep8 compliant or formatted in the correct style, but it was my understanding that time was most important.

Aside from that, I know that we suggest things architecturally that are not always in alignment with the community, but I think that's part of the nature of open source software. I make architectural suggestions based on my previous successes and failures and rarely based on just preference. I think that type of discussion is healthy and helps groups grow. That said, I won't bring these type of ideas or concepts again without code to show. I can't always promise that my code will fit everyone's desires, but that's why the merge-prop/voting system works so well.

Daryl
________________________________________
From: Jay Pipes [jaypipes at gmail.com]
Sent: Thursday, February 21, 2013 2:41 PM
To: openstack-qa at lists.openstack.org
Subject: Re: [openstack-qa] On refactoring of base classes/infrastructure

As mentioned on IRC, if we go with the domain object approach, I really
don't see the point of having our own rest client(s). The upstream
python clients already do this, so what exactly are we gaining by
re-doing the stuff that's in the upstream library.

The only thing that would be different is the XML communication, since
no upstream client uses XML. They all use JSON.

I need to see code examples if we are to discuss this topic any further.
I know you have both said that you've been working on various things
over the last three months or so, but I haven't seen any code, and when
we do see code, it's styled and written entirely different from the rest
of tempest's codebase, which makes it exceedingly difficult to review
and means it doesn't pass basic pep8 or style checks.

Just being honest here, guys. I'm not saying you haven't been working on
Tempest-related stuff, just that the RAX qa team in general tends to be
quite different from the rest of the qa contributors in that you go off
for long periods of time behind the proverbial cubicle walls and don't
particularly communicate upstream what you are working on, and when we
do see code, it's not in-line with where the rest of the community is going.

Best,
-jay

On 02/21/2013 02:40 PM, Sam Danes wrote:
> +1 with the marshaling approach. For my two cents, domain objects that handle the data transformation (marshaling to/from JSON/XML) are a much cleaner class design. Strict XML and JSON clients creates at least partially duplicated client logic for the sake of format. A marshaling approach would help tighten up the infrastructure and allow for more modular executions, IE run the XYZ tests as JSON, then run them as XML. You get faster feedback on the pass/fail state of tests too. Also, as Daryl points out having the requests/responses in a more domain object like structure allows for more simple updates when/if formats change, etc... without having to directly (or at least greatly) impact client(s).
>
> -----Original Message-----
> From: Daryl Walleck [mailto:daryl.walleck at RACKSPACE.COM]
> Sent: Thursday, February 21, 2013 1:05 PM
> To: All Things QA.
> Subject: Re: [openstack-qa] On refactoring of base classes/infrastructure
>
> I think the intent of having XML and JSON running tests is a great idea, the implementation I think could use some redesign. To me, whether I want to use XML or JSON requests is more of a configuration level detail as opposed to a fixture detail. The clients themselves don't really need to be specific to a format either. The only thing that differs is the serialization and deserialization of the request and response, where the serializer/deserializer could be a member of the client class instantiated based on configuration. If you take that a step further, you can refactor the requests and responses out of the clients into their own classes, and let each class take care of the serialization process. Either way, avoiding duplicated client code could help with tightening up the infrastructure of Tempest.
>
> Daryl
> ________________________________________
> From: Jay Pipes [jaypipes at gmail.com]
> Sent: Thursday, February 21, 2013 11:48 AM
> To: openstack-qa at lists.openstack.org
> Subject: Re: [openstack-qa] On refactoring of base classes/infrastructure
>
> On 02/21/2013 11:52 AM, Attila Fazekas wrote:
>> Probably we can came up with a solution, to move both xml and json clients to the same file (per remote service) and still keep it small.
>> We should use the rest API's key naming in our code even, even if it would violate, the python variable naming conventions.
>
> Sure on a single file. Not sure why we'd want to violate our variable naming conventions, though. -1 on that.
>
>> The rest_clients /service proxies/ does lazy authentication, so if they not used, they does not have significant cost.
>> We are now creating "demo" users too frequently, probably we just need to create users just per process, and we just had get a token (excluding keystone test) only once  (unless it expires, but usually they have 24h lifetime).
>> The current behavior spend measurable additional unnecessary time in chatting with keystone.
>
> 100% agreed.
>
>> There is lot of code duplication and other anomalies in our base test classes.
>> First, we should have 4 more generic base classes
>> - One for both XML/JSON
>> - One for pythton-client libs
>
> We already have this...
>
> https://github.com/openstack/tempest/blob/master/tempest/test.py
>
>> - One for AWS/Boto
>> - One for CLI
>
> Sure, ok, if not already done...
>
>> Both of them, should cover all functionality regardless to the remote service type.
>>
>> Slowly we should make them more similar to each other....
>>
>> Most of the whitebox features, should go to some utils like place.
>
> ++
>
> -jay
>
> _______________________________________________
> 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
>

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



More information about the openstack-qa mailing list