[openstack-qa] Data encapsulation within Tempest
tkammer at redhat.com
Mon Jun 10 14:41:03 UTC 2013
Thanks Sean, Matt,
I think I'll take your advise and build a prototype/POC/snippet to try and better explain what I mean.
In the mean time, I'll start contributing in code reviews and/or tests once I return from my vacation :)
Have a good week everyone,
----- Original Message -----
From: "Matthew Treinish" <mtreinish at kortar.org>
To: "All Things QA." <openstack-qa at lists.openstack.org>
Sent: Monday, June 10, 2013 5:15:15 PM
Subject: Re: [openstack-qa] Data encapsulation within Tempest
On Mon, Jun 10, 2013 at 09:18:32AM -0400, Tal Kammer wrote:
> I fail to see how is it close to that model today.
> We have a lot of duplicate code in pretty much every implementation of XML vs JSON..
So are you suggesting we have a uniform client and just have a
serializer/deserializer option for XML or JSON. That would actually end up not
saving that much code. The issue is that XML behavior is different enough from
JSON (at least in nova) that we basically have to handle everything separately.
So there isn't actually that much to combine. It would just be the actually
request call which is only a few lines per request. (To format the url and then
to make the rest_client call) I feel that keeping them separate makes more sense
because of all the differences it would get more complicated to handle everything
in one class. We looked at this when we initially did the XML work, but it ended
up being more confusing because of how XML is used in the projects.
> what will happen if tomorrow we move to SOAP? do we really want to build a new client for every single component? (as it is now..)
If the expected behavior for a new component is different then you will have to
write new clients for the component, that won't change. Are any projects moving
to a SOAP model I find that fairly unlikely. If so then tempest would need some
more re-architecture (like a soap_client instead of rest_client for example) so
adding new clients is the smallest part of it.
> if we look at the rest_client module as it is today, let's take the "identity_auth_v3" for example, what happens when a auth_v4 comes out? v5? do we just keep adding layers?
So the v3 code is still new I haven't really looked to in depth at it. So it's
more than likely it needs some cleaning up to make it more pluggable with v2. But,
we are going to use all the api versions that are still supported by the other
projects. If/when a v4 keystone api comes out I doubt that they will continue to
support v2, but if that is the case then tempest would have to have clients for
all 3 versions, and we'd want to test with all of them.
> Having a model of a "Request" object (or any other name/object, the implementation itself is not relevant for the argument) immediately removes all duplication in clients (which is a lot of code), and a lot more code if we consider add ons in the future. (and I do believe we should consider the future..)
As Sean said the rest client handles most of the common request code right now.
What exactly do you feel is duplicated in the clients right now? All the
duplication I can see is making the request call and formatting urls. These are
pretty slim and formatting the url has to be done per client because there isn't
anything common in the url except the endpoint.(which isn't normally handled in
the clients anyway) The only thing the clients do is handle the request and
response bodies which is also not common because the aren't exactly uniform.
So where exactly do you see duplication?
> Also, all response handling is hard coded, why not separate it into a class/module of it's own?
> Currently, if devs decide to change the response code, there is no graceful way of handling it. everything will pretty much fail..
That's the point, part of tempest reason for existence is to make sure that
response code changes and other api changes get picked up in the gate. If the
change is required in the project then it will most likely require the use of
the "tempest two step".
> If we agree that things can be cleaner, why not start the cleaning process? If it's a matter of time, I am more than willing to volunteer.
I'm not exactly sure what you're shooting for here. But, if you've got an idea
in mind why don't you prototype it a bit and push out a WIP patch so we can all
see exactly what your ideas are.
> ----- Original Message -----
> From: "Sean Dague" <sean at dague.net>
> To: "All Things QA." <openstack-qa at lists.openstack.org>
> Sent: Monday, June 10, 2013 3:48:35 PM
> Subject: Re: [openstack-qa] Data encapsulation within Tempest
> On 06/09/2013 05:54 PM, Daryl Walleck wrote:
> >>> 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.
> Realistically, Tempest is close to that model today anyway, all the best
> REST handling happens in common. It could be made cleaner, for sure, but
> I'd be surprised if you dropped all that much code in the process.
> Sean Dague
openstack-qa mailing list
openstack-qa at lists.openstack.org
More information about the openstack-qa