Open Stack

On 9/16/2019 4:53 AM, Ghanshyam Mann wrote:
> I would like to have a conclusion on this so that Tempest can verify or leave the Volume API for strict validation.

In Nova, when changing the request or response contents, it's pretty 
simple - we always microversion those. Why? Because if my application is 
written to work against different OpenStack clouds, maybe multiple 
public clouds or maybe a hybrid environment where it's running in both 
my local private cloud and in let's say VEXXHOST, and I need to know 
what I can do on each cloud, I use microversions, e.g. just because 
something works on the version of OpenStack I have running in private 
doesn't mean it's going to work in the public cloud provider I'm using 
and vice-versa.

I think generally the people that are OK with not versioning additions 
to a response justify it by saying if the app code isn't looking for 
that specific field anyway they won't notice or care, and if they are 
looking for a specific field, they should treat all fields as optional 
and fallback gracefully. That may work in some cases, but I don't think 
as a general rule that's something we should be following since we don't 
know the situation for the app code or how the field is going to be 
used. For example, maybe the app code wouldn't make an initial request 
to perform some action on the resource if they know they can't properly 
monitor it with a later GET response. So rather than say a microversion 
for response changes is OK in some cases and not others, just keep it 
simple and always require it.

The problem we've faced in nova several times when asking if we need a 
microversion is more about behavioral changes that signal when you can 
do something in the API, since that's a grey area. For example, we added 
a microversion when we added support for multiattach volumes even though 
the type of volume you're using or the compute driver your VM is on 
might not support multiattach. Feature discovery is still a problem in 
OpenStack but at least with the microversion you can determine via API 
version discovery which cloud supports the feature at a basic level and 
which doesn't. Any issues you hit after that are likely due to the cloud 
provider's configuration, which as a user yes that sucks, but we as a 
community haven't solved the "capability discovery" problem and likely 
never will at this rate of development. Anyway, that's a tangent, but my 
point is it's much easier to enforce a consistent development policy for 
request/response changes than it is for behavioral changes.

-- 

Thanks,

Matt