openstack-qa-team team mailing list archive

[Anne Gentle <anne@xxxxxxxxxxxxx>]

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*
anne@xxxxxxxxxxxxx
 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 <david.kranz@xxxxxxxxxx>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<openstack-qa-team@xxxxxxxxxxxxxxxxxxx>
> 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>
>