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