Open Stack

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