[openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing

Chris Hoge chris at openstack.org
Tue Jun 14 23:19:11 UTC 2016


> On Jun 14, 2016, at 3:59 PM, Edward Leafe <ed at leafe.com> wrote:
> 
> On Jun 14, 2016, at 5:50 PM, Matthew Treinish <mtreinish at kortar.org> wrote:
> 
>> But, if we add another possible state on the defcore side like conditional pass,
>> warning, yellow, etc. (the name doesn't matter) which is used to indicate that
>> things on product X could only pass when strict validation was disabled (and
>> be clear about where and why) then my concerns would be alleviated. I just do
>> not want this to end up not being visible to end users trying to evaluate
>> interoperability of different clouds using the test results.
> 
> +1
> 
> Don't fail them, but don't cover up their incompatibility, either.
> -- Ed Leafe

That’s not my proposal. My requirement is that vendors who want to do this
state exactly which APIs are sending back additional data, and that this
information be published.

There are different levels of incompatibility. A response with additional data
that can be safely ignored is different from a changed response that would
cause a client to fail.

One would hope that micro-versions would be able to address this exact
issue for vendors by giving them a means to propose optional but 
well-defined API response additions (not extensions) that are defined
upstream and usable by all vendors. If it’s not too off topic, can someone
from the Nova team explain how something like that would work (if it
would at all)?

-Chris


More information about the OpenStack-dev mailing list