<div class="zcontentRow"> <p>Yea, the situation described below is imagable.</p><p><br></p><p>And all things seem to be a measure and tradeoff, i.e.,  if the feature is supported by a big part of the backends and can be deemed as something like "main trend", then we should test it in Tempest, though inevitably we will suffer the procedure of fail-＞troubleshoot-＞skip in some third party CI, but not everything can be perfect in the world, again, it's a tradeoff.</p><p><br></p><p>And as to how to decide what feature is "main trend" feature, maybe we can have a mechanism of voting, just as how we decide the <span style="line-height: 21px;">core-functionality set.</span></p><p><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"> ＜sean.mcginnis@gmx.com＞;</span></div><div><strong language-data="HistoryTOTxt">To: </strong><span class="zreadUserName" style="display: inline-block;"> ＜openstack-dev@lists.openstack.org＞;</span></div><div><strong language-data="HistoryDateTxt">Date: </strong><span class="">2017/05/03 21:35</span></div><div><strong language-data="HistorySubjectTxt">Subject: </strong><span class="zreadTitle"><strong>Re: [openstack-dev] [qa][cinder][ceph] should Tempest tests thebackend specific feature?</strong></span></div></div><p class="zhistoryContent"><br></p><div>On Wed, May 03, 2017 at 01:14:18PM +0000, Andrea Frittoli wrote:<br>＞ <br>＞ ＞ ＞<br>＞ <br>＞ ＞ Now that this is all in place, I think it's working well and I would like<br>＞ ＞ to see it continue that way. IMO, tempest proper should not have anything<br>＞ ＞ that isn't universally applicable to real world deployments. Not just for<br>＞ ＞ things like Ceph, but things like the manage/unmanage backend specific<br>＞ ＞ tests that were added and broke a large majority of third party CI.<br>＞ ＞<br>＞ <br>＞ Is there a policy in Cinder that a backend must implement a certain set of<br>＞ APIs? If so we could think of testing only that set of APIs in Tempest, so<br>＞ that<br>＞ any app developer knows that he/she can rely on that minimum set of APIs.<br>＞ <br><br>Yes, there is a minimum feature set that all backend drivers must support.<br>That base functionality can be found here [0] and here [1].<br><br>[0] https://docs.openstack.org/developer/cinder/devref/drivers.html#core-functionality<br>[1] https://github.com/openstack/cinder/blob/master/cinder/interface/volume_driver.py<br><br>The issue we've had with some of the tempest tests isn't actually around<br>whether the given backend supports the API. It's the way the API is used<br>that becomes a challenge.<br><br>I'll use the manage/unmanage snapshot one as an example. This is not one<br>of the required APIs, but many backends do support it. But the way this<br>API works is you are basically saying "manage this snapshot that you<br>identify as X", where "X" can be different things depending on the volume<br>driver being used. It's the storage device's native way of identifying<br>a snapshot, which may or may not be our Cinder snapshot ID.<br><br>So that test was added based on the way the LVM driver works for this.<br>That part is great, we get some more code coverage in the gate. But then<br>each volume driver that uses a different ID had to first a) start failing<br>CI, b) troubleshoot what happened to cause this new failure, c) reconfig<br>their CI to skip this test. Repeat cycle for each test added that does<br>something specific to how one or a small subset of backends work.<br><br><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></div><p><br></p></div></div></div></div><p><br></p> </div>