<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">><br>
> On the more ambitious side, I think we could also optimize around the idea<br>
> that some parts of the system aren't even present for some tests. For<br>
> example, most of our tests don't even use GFAPI and won't be affected by a<br>
> GFAPI-only change. Conversely, GFAPI tests won't be affected by a FUSE-only<br>
> change. AFR, EC, and JBR code and tests are mutually exclusive in much the<br>
> same way. We have the burn-in test to catch "stragglers" and git to revert<br>
> any patch with surprising effects, so IMO (at least on master) we should be<br>
> pretty aggressive about pruning out tests that provide little value.<br>
<br>
</span>Raghavendra has been working on a patchset that does a better job of<br>
segregating tests by module. I'll let him explain the specifics.<br></blockquote><div><br></div><div> tests directory uses two different taxonomies today. One is by type of tests where you find bugs/ performance/ basic/ etc. The other of type of feature where you have features/ experimental/ bitrot/ georep/ etc. I am working on moving all into first category where we have</div><div><br></div><div>1. functional/ basic</div><div>2. regression</div><div>3. performance (example: measure time for kernel untar with and without patch)</div><div>4. integration (tests with samba/qemu/nfs-ganesha)</div><div>5. stress (ambitious for now, mentioned for completeness)</div><div>6. upgrade/update (we should not be breaking updates)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
My vision in this regard is something like this:<br>
* A patchset gets Verified +1.<br>
* A meta job is kicked off which determines regression jobs to run.<br>
If the patch only touches GFAPI, we kick off the GFAPI regression tests. If<br>
it touches multiple modules, we kick off the tests for these specific<br>
modules.<br></blockquote><div>As explained in the other reply this is not that trivial. Most of the components do interact with each other and may break the functionality. It is only modules which provide alternate functionality like AFR, EC and JBR that can be tested exclusive manner.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* The results for each platform are aggregated under our current labels similar<br>
to how we aggregate results of multiple tests into one label for smoke.<br></blockquote><div><br></div><div>This is possible.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Am I being too ambitious here? Is there something I'm missing?<br>
<br>
--<br>
nigelb<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
</div></div></blockquote></div><br></div></div>