Here's a full spec in xml, I believe: https://github.com/openstack/compute-api/tree/master/openstack-compute-api- 1.1/src
Gabe On 10/17/11 1:19 PM, "David Kranz" <david.kr...@qrclab.com> wrote: >On 10/17/2011 1:02 PM, Ngo, Donald (HP Cloud Services : QA) wrote: >> Is this what you are looking for?: http://docs.openstack.org/api/ -> >>http://docs.openstack.org/api/openstack-compute/1.1/content/ >> >> >> Donald > >Perhaps so. I had looked at that document but the fact that it is >labeled as a developer's guide rather than a spec and talked about >"Examples" made me think it might not be complete. The fact that it >used XML extensively also made me think there would be an XML Schema >somewhere. But if it is intended to be complete and not have a Schema >then I will go with that. > > -David > > >> >> >> -----Original Message----- >> From: openstack-qa-team-bounces+donald.ngo=hp....@lists.launchpad.net >>[mailto:openstack-qa-team-bounces+donald.ngo=hp....@lists.launchpad.net] >>On Behalf Of David Kranz >> Sent: Monday, October 17, 2011 9:15 AM >> To: openstack-qa-team@lists.launchpad.net >> 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 >> > > >-- >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 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 : openstack-qa-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-qa-team More help : https://help.launchpad.net/ListHelp
