Open Stack

Hi Viktor,

2015-08-17 23:26 GMT-07:00 Tikkanen, Viktor (Nokia - FI/Espoo)
<viktor.tikkanen at nokia.com>:
>
> I have I question regarding validating responses during API tests.
>
> Has it been decided some time ago that no additional properties
> are allowed when verifying response schemas during API tests?

There was the related mail:

http://lists.openstack.org/pipermail/openstack-dev/2015-February/057613.html

> I have an OpenStack based product that contains few additional
> properties in it's compute API and few tempest cases fail like:
>
> tempest_lib.exceptions.InvalidHTTPResponseBody: HTTP response body is invalid json or xml
> Details: HTTP response body is invalid (Additional properties are not allowed (u'nics' was unexpected)
>
> So currently I have to update related schema descriptions located
> under tempest/api_schema/ in order to get those tests passed.
>
> Just wondering if there is some more convenient way to handle such
> kind of drawbacks. Could this schema validating be more flexible
> (e.g. with posibility to define additional properties in some single
> place like tempest.conf file)?

Is it difficult to make these properties upstream?
Vendor specific properties will make API different between clouds, and
that will make the interoperability difficult.
There was a defcore(interoperability) discussion also related to this:
http://lists.openstack.org/pipermail/defcore-committee/2015-June/000849.html

As the above mails, current schemas are blocking additional properties for
* (community devs) accidental additional properties without a new microversion
* (interoperability) vendor-specific properties

Technically, it is possible to relax this additional properties
validation on Tempest side because we have implemented similar feature
on Nova side[1].
But before that, I'd like to know whether that is a right direction or not.

Thanks
Ken Ohmichi
---
[1]: https://review.openstack.org/#/c/193858/