<div dir="ltr"><br><div>To make things relatively easy for the cleanup () function in the test framework, I think it would be better to ensure that uss.t itself deletes snapshots and the volume once the tests are done. Patch [1] has been submitted for review.</div><div><br></div><div>[1] <a href="https://review.gluster.org/#/c/glusterfs/+/22649/">https://review.gluster.org/#/c/glusterfs/+/22649/</a></div><div><br></div><div>Regards,</div><div>Raghavendra</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 30, 2019 at 10:42 AM FNU Raghavendra Manjunath <<a href="mailto:rabhat@redhat.com">rabhat@redhat.com</a>> wrote:<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 dir="ltr"><div dir="ltr"><br><div>The failure looks similar to the issue I had mentioned in [1]</div><div><br></div><div>In short for some reason the cleanup (the cleanup function that we call in our .t files) seems to be taking more time and also not cleaning up properly. This leads to problems for the 2nd iteration (where basic things</div><div>such as volume creation or volume start itself fails due to ENODATA or ENOENT errors).</div><div><br></div><div>The 2nd iteration of the uss.t ran had the following errors.</div><div><br></div><div>"[2019-04-29 09:08:15.275773]:++++++++++ G_LOG:./tests/basic/uss.t: TEST: 39 gluster --mode=script --wignore volume set patchy nfs.disable false ++++++++++</div><div>[2019-04-29 09:08:15.390550] : volume set patchy nfs.disable false : SUCCESS</div><div>[2019-04-29 09:08:15.404624]:++++++++++ G_LOG:./tests/basic/uss.t: TEST: 42 gluster --mode=script --wignore volume start patchy ++++++++++</div><div>[2019-04-29 09:08:15.468780] : volume start patchy : FAILED : Failed to get extended attribute trusted.glusterfs.volume-id for brick dir /d/backends/3/patchy_snap_mnt. Reason : No data available</div><div>"</div><div><br></div><div>These are the initial steps to create and start volume. Why trusted.glusterfs.volume-id extended attribute is absent is not sure. The analysis in [1] had errors of ENOENT (i.e. export directory itself was absent).</div><div>I suspect this to be because of some issue with the cleanup mechanism at the end of the tests.</div><div><br></div><div>[1] <a href="https://lists.gluster.org/pipermail/gluster-devel/2019-April/056104.html" target="_blank">https://lists.gluster.org/pipermail/gluster-devel/2019-April/056104.html</a></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 30, 2019 at 8:37 AM Sanju Rakonde <<a href="mailto:srakonde@redhat.com" target="_blank">srakonde@redhat.com</a>> wrote:<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 dir="ltr"><div dir="ltr">Hi Raghavendra,<div><br></div><div><span style="color:rgb(51,51,51);font-size:14px;white-space:pre-wrap">./tests/basic/uss.t </span>is timing out in release-6 branch consistently. One such instance is <a href="https://review.gluster.org/#/c/glusterfs/+/22641/" target="_blank">https://review.gluster.org/#/c/glusterfs/+/22641/</a>. Can you please look into this?<br><div><div><br></div>-- <br><div dir="ltr" class="gmail-m_2413148880114628941gmail-m_7922542964927774167gmail_signature"><div dir="ltr"><div>Thanks,<br></div>Sanju<br></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div>