Chris, If we add openstack config to refstack submission will that provide sufficient info for "interoperability" LOGO? That includes version of APIs for each service. https://review.openstack.org/#/c/300057/
Thanks, Arkady -----Original Message----- From: Chris Hoge [mailto:[email protected]] Sent: Wednesday, June 22, 2016 1:37 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing > On Jun 22, 2016, at 11:24 AM, Sean Dague wrote: > > On 06/22/2016 01:59 PM, Chris Hoge wrote: >> >>> On Jun 20, 2016, at 5:10 AM, Sean Dague >>> > wrote: >>> >>> On 06/14/2016 07:19 PM, Chris Hoge wrote: >>>> >>>>> On Jun 14, 2016, at 3:59 PM, Edward Leafe >>>>> > wrote: >>>>> >>>>> On Jun 14, 2016, at 5:50 PM, Matthew Treinish >>>>> > 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: > [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
