> On Jun 22, 2016, at 11:24 AM, Sean Dague <s...@dague.net> wrote: > > 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.
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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ 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
