openstack-qa-team team mailing list archive

[Gabe Westmaas <gabe.westmaas@xxxxxxxxxxxxx>]

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.kranz@xxxxxxxxxx> 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.com@xxxxxxxxxxxxxxxxxxx
>>[mailto:openstack-qa-team-bounces+donald.ngo=hp.com@xxxxxxxxxxxxxxxxxxx]
>>On Behalf Of David Kranz
>> Sent: Monday, October 17, 2011 9:15 AM
>> To: openstack-qa-team@xxxxxxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxxxxxx
>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.