openstack-qa-team team mailing list archive

[David Kranz <david.kranz@xxxxxxxxxx>]

On 10/17/2011 8:11 AM, Aaron Lee wrote:
> It looks like we have two different issues we are trying to solve here. The first is testing Nova itself, and the second is testing a wrapper to interface with Nova. I think the wrappers should be tested within their own projects. And as long as the wrapper is well understood enough it should be sufficient for testing Nova directly.
I was really talking about the wrapper. I know there are valid reasons 
for defining the OpenStack APIs as  HTTP services but no one wants to 
code to that low-level, serialized format unless they are actually 
writing a unit test for the HTTP API implementation itself.  So other 
collections of code that want to call these APIs, including the nova 
implementation itself, define their own classes and methods to provide a 
suitable abstraction. I was suggesting that there should be one endorsed 
and maintained official wrapper that provides a signature and 
class-based API to, for example, the OpenStack Compute HTTP API.  That 
would probably be a python API since the rest of the code is python but 
there could be others as well.

By the way, I was unable to find a spec, xml schema, etc. that actually 
defines the arguments and return values for the HTTP OpenStack Compute 
API. Is there such a thing?

 -David


> Daryl brings up a good point that we are going to have to worry about accessing Nove during the different phases of each test. If we don't trust the client enough to make the call we are testing, maybe we could build and call that url directly from the test. However maintaining these tests is going to be a huge pain(and time sink) if we expect everything to be set up by directly. In this case we could use a wrapper for setup, verification, and teardown, and call the tested action directly. If this is abstracted properly then we should only use httplib2 directly in the tests, and only use novaclient directly in the setup, teardown, and verification helpers.
>
> Thanks for all the feedback,
> Aaron
>
> O