Open Stack

On 06/14/2016 07:19 PM, Chris Hoge wrote:
> 
>> 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.

It's actually not different. It's really not.

This idea that it's safe to add response data is based on an assumption
that software versions only move forward. If you have a single deploy of
software, that's fine.

However as noted, we've got production clouds on Juno <-> Mitaka in the
wild. Which means if we want to support horizontal transfer between
clouds, the user experienced timeline might be start on a Mitaka cloud,
then try to move to Juno. So anything added from Juno -> Mitaka without
signaling has exactly the same client breaking behavior as removing
attributes.

Which is why microversions are needed for attribute adds.

	-Sean

-- 
Sean Dague
http://dague.net