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