<div dir="auto"><div>Hi Amar,<br><div class="gmail_extra"><br><div class="gmail_quote">On 28 Jan 2018 06:50, "Amar Tumballi" <<a href="mailto:atumball@redhat.com">atumball@redhat.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for this experiment, Xavi!!<div><br></div><div>I see two proposals here in the thread.</div><div><br></div><div>1. Remove unnecessary sleep commands.</div><div>2. Try to bring explicit checks, so our tests are more consistent.</div><div><br></div><div>I am personally in favor of 1. Lets do this.</div><div><br></div><div>About 2, as its already discussed, we may get into issues due to many outside glusterfs project setups causing much harder problems to debug. Not sure if we should depend on our 'eventing' framework in such test cases ? Would that help?</div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">That would be a good way to detect when something can be done. I've not worked in these lines yet. But this is not the only way. For example, in the kill_brick command there was a sleep after that to give time glusterd to be aware of the change. Instead of the sleep, we can directly request glusterd the state of the brick. If it's down, we are done without needing to wait unnecessarily. If for some reason it takes more than one second, we won't fail spuriously because we are directly checking the state. For extreme cases where something really fails, we can define a bigger timeout, for example 5 seconds. This way we cover all cases but in the most common case it will only take some tens or hundreds of milliseconds. </div><div dir="auto"><br></div><div dir="auto">Reducing timeouts have made more evident some races that currently exist in the code. Till now I've identified a bug in AFR and a couple of races in RPC code than were causing spurious failures. I still have to identify another race (probably in RPC also) that is generating unexpected disconnections (or incorrect reconnections).</div><div dir="auto"><br></div><div dir="auto">Xavi</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Regards,</div><div>Amar</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div class="elided-text">On Thu, Jan 25, 2018 at 8:07 PM, Xavi Hernandez <span dir="ltr"><<a href="mailto:jahernan@redhat.com" target="_blank">jahernan@redhat.com</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Thu, Jan 25, 2018 at 3:03 PM, Jeff Darcy <span dir="ltr"><<a href="mailto:jeff@pl.atyp.us" target="_blank">jeff@pl.atyp.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div><span class="m_-8778426524986355447m_1550564245458868995gmail-"><div style="font-family:Arial"><br></div>
<div><br></div>
<div><br></div>
<div>On Wed, Jan 24, 2018, at 9:37 AM, Xavi Hernandez wrote:<br></div>
<blockquote type="cite"><div dir="ltr"><div><div><div>That happens when we use arbitrary delays. If we use an explicit check, it will work on all systems.<br></div>
</div>
</div>
</div>
</blockquote><div style="font-family:Arial"><br></div>
</span><div style="font-family:Arial">You're arguing against a position not taken. I'm not expressing opposition to explicit checks. I'm just saying they don't come for free. If you don't believe me, try adding explicit checks in some of the harder cases where we're waiting for something that's subject to OS scheduling delays, or for large numbers of operations to complete. Geo-replication or multiplexing tests should provide some good examples. Adding explicit conditions is the right thing to do in the abstract, but as a practical matter the returns must justify the cost.<br></div>
<div style="font-family:Arial"><br></div>
<div style="font-family:Arial">BTW, some of our longest-running tests are in EC. Do we need all of those, and do they all need to run as long, or could some be eliminated/shortened?</div></div></blockquote><div><br></div></span><div>Some tests were already removed some time ago. Anyway, with the changes introduced, it takes between 10 and 15 minutes to execute all ec related tests from basic/ec and bugs/ec (an average of 16 to 25 seconds per test). Before the changes, the same tests were taking between 30 and 60 minutes.</div><div><br></div><div>AFR tests have also improved from almost 60 minutes to around 30.</div><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span class="m_-8778426524986355447m_1550564245458868995gmail-">
<div style="font-family:Arial"><br></div>
<blockquote type="cite"><div dir="ltr"><div><div><div>I agree that parallelizing tests is the way to go, but if we reduce the total time to 50%, the parallelized tests will also take 50% less of the time.<br></div>
</div>
</div>
</div>
</blockquote><div style="font-family:Arial"><br></div>
</span><div style="font-family:Arial">Taking 50% less time but failing spuriously 1% of the time, or all of the time in some environments, is not a good thing. If you want to add explicit checks that's great, but you also mentioned shortening timeouts and that's much more risky.<br></div>
</div>
</blockquote></span></div><br></div><div class="gmail_extra">If we have a single test that takes 45 minutes (as we currently have in some executions: bugs/nfs/bug-1053579.t), parallelization won't help much. We need to make this test to run faster.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Some tests that were failing after the changes have revealed errors in the test itself or even in the code, so I think it's a good thing. Currently I'm investigating what seems a race in the rpc layer during connections that causes some tests to fail. This is a real problem that high delays or slow machines were hiding. It seems to cause some gluster requests to fail spuriously after reconnecting to a brick or glusterd. I'm not 100% sure about this yet, but initial analysis seems to indicate that.</div><span class="m_-8778426524986355447HOEnZb"><font color="#888888"><div class="gmail_extra"><br></div><div class="gmail_extra">Xavi</div></font></span></div>
<br></div><div class="quoted-text">______________________________<wbr>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-devel</a><br></div></blockquote></div><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_-8778426524986355447gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div>
</font></div>
</blockquote></div><br></div></div></div>