> On Jun 20, 2016, at 5:10 AM, Sean Dague <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> wrote: >>> >>> On Jun 14, 2016, at 5:50 PM, Matthew Treinish <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. -Chris > -Sean > > -- > Sean Dague > http://dague.net <http://dague.net/> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org > <mailto:openstack-dev-requ...@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>
__________________________________________________________________________ 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
