-----Original Message-----
From: openstack-qa-team-bounces+donald.ngo=hp.com@xxxxxxxxxxxxxxxxxxx [mailto:openstack-qa-team-bounces+donald.ngo=hp.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of David Kranz
Sent: Monday, October 17, 2011 9:15 AM
To: openstack-qa-team@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack-qa-team] Python wrappers for OpenStack APIs
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
