Open Stack

> On Jun 20, 2016, at 5:10 AM, Sean Dague <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> 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.

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.

-Chris


> 	-Sean
> 
> -- 
> Sean Dague
> http://dague.net <http://dague.net/>
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160622/202d7085/attachment.html>