Open Stack

Excerpts from Chris Hoge's message of 2016-06-14 16:19:11 -0700:
> 
> > 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.

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