[openstack-qa] Data encapsulation within Tempest
sean at dague.net
Mon Jun 10 14:09:40 UTC 2013
On 06/10/2013 09:18 AM, 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..
> 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 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?
Identity v4 would presumably be different enough from identity v3, that
there would probably not be a huge amount of code reuse. Nova v2 -> v3
is a little bit breaking with this model.
> 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..)
> 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..
Currently if devs decide to change the response code that's an API
violation, and should be stopped. So optimizing for that use case really
isn't the best idea.
> 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 have no issues with cleanups. :) I'll happily review them.
I think the best place to go from here is some sample of what it would
look like that could be concrete. Start with one of the smaller clients
and work out from there.
I also really think this work needs to dovetail in getting us over to
fixtures for testr. Jay already started with some ideas there, Matt's
trying to drive some examples on the images clients.
I'm all for a more compact and cleaner code base to encourage additional
More information about the openstack-qa