[openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing
chris at openstack.org
Wed Jun 22 17:59:00 UTC 2016
> 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.
>>> 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
> 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.
> 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...
More information about the OpenStack-dev