<div class="zcontentRow"><p style="font-size:16px;font-family:arial;"><span style="font-size: small; orphans: 2; white-space: pre-wrap; widows: 2; background-color: rgb(255, 255, 255);">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.</span></p><p style="font-size:16px;font-family:arial;"><br></p><div><div class="zhistoryRow" style="display:block"><div class="zhistoryDes" style="width: 100%; height: 28px; line-height: 28px; background-color: #E0E5E9; color: #1388FF; text-align: center;" language-data="HistoryOrgTxt">Original Mail</div><div id="zwriteHistoryContainer"><div class="control-group zhistoryPanel"><div class="zhistoryHeader" style="padding: 8px; background-color: #F5F6F8;"><div><strong language-data="HistorySenderTxt">Sender: </strong><span class="zreadUserName">GhanshyamMann <gmann@ghanshyammann.com></span></div><div><strong language-data="HistoryTOTxt">To: </strong><span class="zreadUserName" style="display: inline;">Sean Mooney <smooney@redhat.com>;</span></div><div><strong language-data="HistoryCCTxt">CC: </strong><span class="zreadUserName" style="display: inline;">Sean McGinnis <sean.mcginnis@gmx.com>;</span><span class="zreadUserName" style="display: inline;">Matt Riedemann <mriedemos@gmail.com>;</span><span class="zreadUserName" style="display: inline;">openstack-discuss <openstack-discuss@lists.openstack.org>;</span></div><div><strong language-data="HistoryDateTxt">Date: </strong><span class="">2019/09/17 08:08</span></div><div><strong language-data="HistorySubjectTxt">Subject: </strong><span class="zreadTitle"><strong>Re: [all][interop][cinder][qa] API changes with/withoutmicroversion and Tempest verification of API interoperability</strong></span></div></div><div class="zhistoryContent"><div> ---- On Tue, 17 Sep 2019 07:59:19 +0900 Sean Mooney <smooney@redhat.com> wrote ----<br> > On Mon, 2019-09-16 at 17:11 -0500, Sean McGinnis wrote:<br> > > > <br> > > > Backend/type specific information leaking out of the API dynamically like<br> > > > that is definitely an interoperability problem and as you said it sounds<br> > > > like it's been that way for a long time. The compute servers diagnostics API<br> > > > had a similar problem for a long time and the associated Tempest test for<br> > > > that API was disabled for a long time because the response body was<br> > > > hypervisor specific, so we eventually standardized it in a microversion so<br> > > > it was driver agnostic.<br> > > > <br> > > <br> > > Except this isn't backend specific information that is leaking. It's just<br> > > reflecting the configuration of the system.<br> > yes and config driven api behavior is also an iterop problem.<br> > ideally you should not be able to tell if cinder is abcked by ceph or emc form the<br> > api responce at all.<br> > <br> > sure you might have a volume type call ceph and another called emc but both should be<br> > report capasty in the same field with teh same unit.<br> > <br> > ideally you would have a snapshots or gigabytes quota and option ly associate that with a volume types<br> > but shanshot_ceph is not interoperable aross could if that exstis with that name solely becaue ceph was used on the<br> > backend. as a client i would have to look at snapshost* to figure out my quotat and in princiapal that is an ubounded<br> > set.<br><br>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.<br>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.<br><br>-gmann  <br><br> > > <br> > <br> > <br> > <br><br></div></div></div></div></div></div><p><br></p></div>