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
--
Mailing list: https://launchpad.net/~openstack-qa-team
Post to : openstack-qa-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-qa-team
More help : https://help.launchpad.net/ListHelp