On 06/22/2016 01:59 PM, Chris Hoge wrote:
>
>> On Jun 20, 2016, at 5:10 AM, Sean Dague <s...@dague.net
>> <mailto:s...@dague.net>> wrote:
>>
>> On 06/14/2016 07:19 PM, Chris Hoge wrote:
>>>
>>>> On Jun 14, 2016, at 3:59 PM, Edward Leafe <e...@leafe.com
>>>> <mailto:e...@leafe.com>> wrote:
>>>>
>>>> On Jun 14, 2016, at 5:50 PM, Matthew Treinish <mtrein...@kortar.org
>>>> <mailto: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.
>
> I’d like to note that Nova v2.0 is still a supported API, which
> as far as I understand allows for additional attributes and
> extensions. That Tempest doesn’t allow for disabling strict
> checking when using a v2.0 endpoint is a problem.
>
> The reporting of v2.0 in the Marketplace (which is what we do
> right now) is also a signal to a user that there may be vendor
> additions to the API.
>
> DefCore doesn’t disallow the use of a 2.0 endpoint as part
> of the interoperability standard.
This is a point of confusion.
The API definition did not allow that. The implementation of the API
stack did.
In Liberty the v2.0 API is optionally provided by a different backend
stack that doesn't support extensions.
In Mitaka it is default v2.0 API on a non extensions backend
In Newton the old backend is deleted.
From Newton forward there is still a v2.0 API, but all the code hooks
that provided facilities for extensions are gone.
-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
