[all][interop][cinder][qa] API changes with/without microversion and Tempest verification of API interoperability
Matt Riedemann
mriedemos at gmail.com
Mon Sep 16 14:20:09 UTC 2019
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
More information about the openstack-discuss
mailing list