[openstack-dev] [QA][tempest] schema extensions
Hi! 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? 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)? -Viktor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA][tempest] schema extensions
Hi Viktor, 2015-08-17 23:26 GMT-07:00 Tikkanen, Viktor (Nokia - FI/Espoo) viktor.tikka...@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/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA][tempest] schema extensions
Thank you for the references! -Original Message- From: ext Ken'ichi Ohmichi [mailto:ken1ohmi...@gmail.com] Sent: Wednesday, August 19, 2015 2:48 AM ... 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 I'm afraid that not all the currently used additional properties can be upstreamed as such (some of them contain e.g. references to vendor's own SW products) but we will probably discuss this possibility with the vendor in the future. 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/ IMO it is not a right direction to permanently relax additional properties validation (for the reasons mentioned above). Actually currently I have to update only the value of additionalProperties in few places. Of course, a common parameter like allow_additional_api_properties (or so) would ease the patching but let's see if somebody else is interested in it... -Viktor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
