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