<div><br><div class="gmail_quote"><div>On Wed, May 3, 2017 at 21:49 Andrea Frittoli <<a href="mailto:andrea.frittoli@gmail.com">andrea.frittoli@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div>On Tue, May 2, 2017 at 6:46 AM Ghanshyam Mann <<a href="mailto:ghanshyammann@gmail.com" target="_blank">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></div><div><div class="gmail_quote"><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></div></blockquote><div><br></div><div>But in this case, features are not discoverable. From API status code only we can get to know whether it is implemented in particular backend or not.  It has same issue for interoperability as Tempest facing now. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div></div></div></div><div><div class="gmail_quote"><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></div><div><div class="gmail_quote"><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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div><div><div class="gmail_quote"><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>
__________________________________________________________________________<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><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><div>-gmann</div></div></div>