Excerpts from Chris Hoge's message of 2016-06-14 16:19:11 -0700: > > > On Jun 14, 2016, at 3:59 PM, Edward Leafe <[email protected]> wrote: > > > > On Jun 14, 2016, at 5:50 PM, Matthew Treinish <[email protected]> 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.
I am reading the responses here as very much supporting that. Doug > > 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
