[all][interop][cinder][qa] API changes with/without microversion and Tempest verification of API interoperability
Matt Riedemann
mriedemos at gmail.com
Mon Sep 16 21:15:54 UTC 2019
On 9/16/2019 12:40 PM, Eric Harney wrote:
>
> There's a lot of talk here about interoperability problems... what are
> those problems, exactly? If we ignore Ocata and just look at Train --
> why is this API not problematic for interoperability there, when
> requests on different clouds would return different data, depending on
> how types are configured?
>
> It's not clear to me that rectifying the microversion concerns around
> the "groups" field is helpful without also understanding this piece,
> because if the concern is that different clouds return different fields
> for this API -- that will still happen. We need more detail to
> understand how to address this, and what the problem is that we are
> trying to solve exactly.
Backend/type specific information leaking out of the API dynamically
like that is definitely an interoperability problem and as you said it
sounds like it's been that way for a long time. The compute servers
diagnostics API had a similar problem for a long time and the associated
Tempest test for that API was disabled for a long time because the
response body was hypervisor specific, so we eventually standardized it
in a microversion so it was driver agnostic.
--
Thanks,
Matt
More information about the openstack-discuss
mailing list