I think the final solution will come from the openstack-integration-tests project. I think the novaclient project would be a reasonable choice if you're looking for a solution immediately. I agree that a good long term solution for httplib type tests would be to have a common request driver so that we can keep the actual requests out of the test code. There's an example of an implementation like this in my GitHub (https://github.com/dwalleck/zodiac), which is a test design pattern I've used in past with great success. I'd be very interested in hearing others opinions on this as well, as I think the decisions we make now will have long term effects on our test infrastructure going forward.
Daryl ________________________________________ From: openstack-qa-team-bounces+daryl.walleck=rackspace....@lists.launchpad.net [openstack-qa-team-bounces+daryl.walleck=rackspace....@lists.launchpad.net] on behalf of David Kranz [[email protected]] Sent: Friday, October 14, 2011 10:11 AM To: [email protected] Subject: [Openstack-qa-team] Python wrappers for OpenStack APIs I have been implementing some functional stress tests for nova. It seems that there are various pieces of Python code that have been written to call the HTTP apis including novaclient as well as code that is part of various test suites. There are also ueca-tools. It seems like it would be useful to have a "standard" set of test driver code going forward. Does any one have any comments about this, or a suggestion about which client API code would be best to use? -David -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. -- Mailing list: https://launchpad.net/~openstack-qa-team Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
