[openstack-qa] Data encapsulation within Tempest

Attila Fazekas afazekas at redhat.com
Tue Jun 11 15:52:35 UTC 2013





----- Original Message -----
> From: "Matthew Treinish" <mtreinish at kortar.org>
> To: "All Things QA." <openstack-qa at lists.openstack.org>
> Sent: Monday, June 10, 2013 4: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.
> 

May be the xml_to_data/xml_to_json  not smart enough. 
I suspect a smarter way can exist.

Not just the serialization could be more generic.
https://github.com/openstack/tempest/commit/d42992849f95ac9a01fc73d2d6216585b6f7d174#L1R312
The above just a small clean up.

Much more can be done.
May be all of the nova API calls can fit into 1-2 normal sized python file.

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

Can we use additional xsd files for XML verification ?
I saw several OpenStack projects have xsd files.

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

But it can be more compact.

> > 
> > 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.
> 
> > 
> > Regards,
> > Tal
> > 
> > ----- 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
> > 
> > --
> > Sean Dague
> > http://dague.net
> 
> 
> -Matt Treinish
> 
> _______________________________________________
> 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