<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, May 2, 2017 at 4:56 PM Sean McGinnis <<a href="mailto:sean.mcginnis@gmx.com">sean.mcginnis@gmx.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, May 02, 2017 at 03:36:20PM +0200, Jordan Pittier wrote:<br>
> On Tue, May 2, 2017 at 7:42 AM, Ghanshyam Mann <<a href="mailto:ghanshyammann@gmail.com" target="_blank">ghanshyammann@gmail.com</a>><br>
> wrote:<br>
><br>
> > 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>
> ><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>
> ><br>
> So basically, if one of the 50 Cinder driver doesn't support a feature, we<br>
> should never test that feature ? What about the 49 other drivers ? If a<br>
> feature exists and can be tested in the Gate (with whatever default<br>
> config/driver is shipped) then I think we should test it.<br>
><br>
50? Over 100 as of Ocata.<br>
<br>
Well, is tempest's purpose in life to provide complete gate test coverage,<br>
or is tempest's purpose in life to give operators a tool to validate that<br>
their deployment is working as expected?<br></blockquote><div><br></div><div>Neither.</div><div><br></div><div>Tempest is used for several different purposes, but I would say it was never</div><div>meant to ensure 100% coverage of the API. It is used by many operators to</div><div>validate their deployments, even if that part is better achieved via the</div><div>"scenario" tests, as opposed to the "API" tests.</div><div><br></div><div>Main use cases for Tempest are:</div><div>- integration (cross-service) testing in the gate</div><div>- help to ensure API backward compatibility / stability</div><div>- home for interoperability tests</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In attempting to do things in the past, I've received push back based on<br>
the argument that it was the latter. For this reason, in-tree tempest tests<br>
were added to Cinder to give us a way to get better test coverage for our<br>
own sake.<br></blockquote><div><br></div><div>There are several use cases for in-tree tests. </div><div>Some examples:</div><div><br></div><div>Test that provide very little cross-service validation (e.g. most API negative</div><div>tests) do not need to be in Tempest. Running a full cloud is expensive</div><div>resource and time-wise, and it's not the best test environment to run a large</div><div>combination of negative test cases.</div><div><br></div><div>Many tests cannot be driven via API. It's very hard for instance to test</div><div>any transient resource state via API, since there's not enough control via the API.</div><div><br></div><div>Scheduler tests are not best implemented via API as well, since they often require</div><div>several nodes and resources when executed in a full cloud environment.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div><br></div><div>Is there a policy in Cinder that a backend must implement a certain set of</div><div>APIs? If so we could think of testing only that set of APIs in Tempest, so that</div><div>any app developer knows that he/she can rely on that minimum set of APIs.</div><div><br></div><div>If the list of APIs is not constrained on cinder side, the next driver could come</div><div>along that does not support an API, and then we would have to stop testing it</div><div>in Tempest - which is not an option.</div><div><br></div><div>Another point is that API that rely on services other than nova are best tested</div><div>in Tempest, so that the tests run in the gate of other services as well - or at</div><div>least the cinder functional test job should run against the other services as well.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Backend specific things should not be part of tempest in my opinion. We<br>
should cover those things through in-tree tempest plugins and our own<br>
testing.<br>
><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>
> ><br>
> Using regex and blacklist, any 3rd party CI can skip any test based on the<br>
> test ID. Without introducing a config flag. See:<br>
> <a href="https://github.com/openstack-infra/project-config/blob/1cea31f402b6b0cccc47cde203c12184b5392c90/jenkins/jobs/devstack-gate.yaml#L1871" rel="noreferrer" target="_blank">https://github.com/openstack-infra/project-config/blob/1cea31f402b6b0cccc47cde203c12184b5392c90/jenkins/jobs/devstack-gate.yaml#L1871</a><br>
><br>
><br>
> > 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>
> Yeah, that's bad.<br>
><br>
> ><br>
> > IMO options 1 is better options. More feedback are welcome.<br>
><br>
><br>
> > ..1 <a href="https://developer.openstack.org/api-ref/block-storage/v3/" rel="noreferrer" target="_blank">https://developer.openstack.org/api-ref/block-storage/v3/</a>?<br>
> > expanded=force-delete-a-backup-detail#force-delete-a-backup<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-" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2017-</a><br>
> > April/115229.html<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>