Open Stack

Seems we can hardly reach an agreement about whether to use microverion for fields added in response, but, I think for tempest, things are simpler, we can add schema check according to the api-ref, and if some issues are found (like groups field) in older version, we can simply remove that field from required fields. That won't happen very often.







Original Mail



Sender: GhanshyamMann <gmann at ghanshyammann.com>
To: Sean Mooney <smooney at redhat.com>;
CC: Sean McGinnis <sean.mcginnis at gmx.com>;Matt Riedemann <mriedemos at gmail.com>;openstack-discuss <openstack-discuss at lists.openstack.org>;
Date: 2019/09/17 08:08
Subject: Re: [all][interop][cinder][qa] API changes with/withoutmicroversion and Tempest verification of API interoperability


 ---- On Tue, 17 Sep 2019 07:59:19 +0900 Sean Mooney <smooney at redhat.com> wrote ----
 > On Mon, 2019-09-16 at 17:11 -0500, Sean McGinnis wrote:
 > > > 
 > > > 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.
 > > > 
 > > 
 > > Except this isn't backend specific information that is leaking. It's just
 > > reflecting the configuration of the system.
 > yes and config driven api behavior is also an iterop problem.
 > ideally you should not be able to tell if cinder is abcked by ceph or emc form the
 > api responce at all.
 > 
 > sure you might have a volume type call ceph and another called emc but both should be
 > report capasty in the same field with teh same unit.
 > 
 > ideally you would have a snapshots or gigabytes quota and option ly associate that with a volume types
 > but shanshot_ceph is not interoperable aross could if that exstis with that name solely becaue ceph was used on the
 > backend. as a client i would have to look at snapshost* to figure out my quotat and in princiapal that is an ubounded
 > set.

Yeah and this is real pain point for end-user or app using API directly. Dynamic API behaviour base don system configuration is interoperability issue.
In bug#1687538 case, new field is going to be reflected for the same backend and same configuration Cloud. Cloud provider upgrade their cloud from ocata->anything and user will start getting the new field without any mechanism to discover whether that field is expected to be present or not.

-gmann  

 > > 
 > 
 > 
 >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190917/859e3ed5/attachment.html>