[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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.