Open Stack

> On Jun 22, 2016, at 11:24 AM, Sean Dague <sean at dague.net> wrote:
> 
> On 06/22/2016 01:59 PM, Chris Hoge wrote:
>> 
>>> On Jun 20, 2016, at 5:10 AM, Sean Dague <sean at dague.net
>>> <mailto:sean at dague.net>> wrote:
>>> 
>>> On 06/14/2016 07:19 PM, Chris Hoge wrote:
>>>> 
>>>>> On Jun 14, 2016, at 3:59 PM, Edward Leafe <ed at leafe.com
>>>>> <mailto:ed at leafe.com>> wrote:
>>>>> 
>>>>> On Jun 14, 2016, at 5:50 PM, Matthew Treinish <mtreinish at kortar.org
>>>>> <mailto: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.
>> 
>> 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.

And downstream vendors took advantage of that. We may
not like it, but it’s a reality in the current ecosystem.

> 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.

It’s really important that the current documentation reflect the
code and intent of the dev team. As of writing this e-mail, 

"• v2 (SUPPORTED) and v2 extensions (SUPPORTED) (Will
be deprecated in the near future.)”[1]

Even with this being removed in Newton, DefCore still has
to allow for it in every supported version.

-Chris

[1] http://docs.openstack.org/developer/nova/

> 	-Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev