> On Jun 14, 2016, at 3:59 PM, Edward Leafe <e...@leafe.com> wrote: > > On Jun 14, 2016, at 5:50 PM, Matthew Treinish <mtrein...@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 __________________________________________________________________________ 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
