<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, May 2, 2017 at 6:46 AM Ghanshyam Mann <<a href="mailto:ghanshyammann@gmail.com">ghanshyammann@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In Cinder, there are many features/APIs which are backend specific and<br>
will return 405 or 501 if same is not implemented on any backend [1].<br>
If such tests are implemented in Tempest, then it will break some gate<br>
where that backend job is voting. like ceph job in glance_store gate.<br></blockquote><div><br></div><div>Having a test in Tempest is important for interoperability and API backward compatibility.</div><div>As long as available features are discoverable and reported in a consistent way, it</div><div>is possible for app developer to write application that will work fine against</div><div>different backends. </div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There been many such cases recently where ceph jobs were broken due to<br>
such tests and recently it is for force-delete backup feature[2].<br>
Reverting force-delete tests in [3]. To resolve such cases at some<br>
extend, Jon is going to add a white/black list of tests which can run<br>
on ceph job [4] depends on what all feature ceph implemented. But this<br>
does not resolve it completely due to many reason like<br>
1. External use of Tempest become difficult where user needs to know<br>
what all tests to skip for which backend<br>
2. Tempest tests become too specific to backend.<br>
<br>
Now there are few options to resolve this:<br>
1. Tempest should not tests such API/feature which are backend<br>
specific like mentioned by api-ref like[1].<br>
2. Tempest test can be disabled/skip based on backend. - This is not<br>
good idea as it increase config options and overhead of setting those.<br></blockquote><div><br></div><div>Tempest has many options because we decide not to rely on discovery, i.e.</div><div>we configure what we expect to find in the target cloud. I don't think we can use</div><div>this as a factor to influence the decision in this case.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. Tempest test can verify behavior with if else condition as per<br>
backend. This is bad idea and lose the test strength.<br>
<br>
IMO options 1 is better options. More feedback are welcome.<br>
<br>
..1 <a href="https://developer.openstack.org/api-ref/block-storage/v3/?expanded=force-delete-a-backup-detail#force-delete-a-backup" rel="noreferrer" target="_blank">https://developer.openstack.org/api-ref/block-storage/v3/?expanded=force-delete-a-backup-detail#force-delete-a-backup</a><br>
..2 <a href="https://bugs.launchpad.net/glance/+bug/1687538" rel="noreferrer" target="_blank">https://bugs.launchpad.net/glance/+bug/1687538</a><br>
..3 <a href="https://review.openstack.org/#/c/461625/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/461625/</a><br>
..4 <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-April/115229.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2017-April/115229.html</a><br>
<br>
-gmann<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>