Hi David - You can get the schema for the Compute API here: https://github.com/openstack/compute-api/tree/master/openstack-compute-api-1.1/src/xsd
Let me know if that works for you. Anne *Anne Gentle* [email protected] my blog <http://justwriteclick.com/> | my book<http://xmlpress.net/publications/conversation-community/>| LinkedIn <http://www.linkedin.com/in/annegentle> | Delicious<http://del.icio.us/annegentle>| Twitter <http://twitter.com/annegentle> On Mon, Oct 17, 2011 at 11:15 AM, David Kranz <[email protected]>wrote: > 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<https://launchpad.net/%7Eopenstack-qa-team> > Post to : > openstack-qa-team@lists.**launchpad.net<[email protected]> > Unsubscribe : > https://launchpad.net/~**openstack-qa-team<https://launchpad.net/%7Eopenstack-qa-team> > More help : > https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp> >
-- 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
