Hi Viktor, 2015-08-17 23:26 GMT-07:00 Tikkanen, Viktor (Nokia - FI/Espoo) <[email protected]>: > > 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/ __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
