[all][interop][cinder][qa] API changes with/without microversion and Tempest verification of API interoperability
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.