+++ This bug was initially created as a clone of Bug #1278476 +++ +++ +++ +++ Bug #1278578 was used to add the test case to bad-tests. +++ +++ This bug is used to re-enable the test case. +++ Description of problem: spurious errors in nfs-auth.t slow regressions. Version-Release number of selected component (if applicable): How reproducible: spurious error, but frequent. Steps to Reproduce: 1. run regression 2. repeat 3. probably within 5 tries the spurious error will be seen. Actual results: test fails. Expected results: test passes. Additional info:
REVIEW: http://review.gluster.org/12663 (tests: fix timeout in mount-nfs-auth.t) posted (#1) for review on release-3.7 by Niels de Vos (ndevos)
REVIEW: http://review.gluster.org/12664 (tests: make mount-nfs-auth.t more stable) posted (#1) for review on release-3.7 by Niels de Vos (ndevos)
COMMIT: http://review.gluster.org/12663 committed in release-3.7 by Niels de Vos (ndevos) ------ commit 9e096b42d9e6448175eecf0e9b979a644c6104b0 Author: Niels de Vos <ndevos> Date: Thu Nov 19 15:57:54 2015 +0100 tests: fix timeout in mount-nfs-auth.t The mount timeout was too short. The normal configuration-change path (construct graph, call reconfigure) and the auth-refresh path might in effect run serially. Therefore we have to wait for the *sum* of those two intervals. As with all too-short-timeout problems, the result was that the test would run fine most of the time. However, it has caused spurious failures on my own patches a half dozen times, and I have a half dozen other emails about it nuking other people's as well (most often but not always on NetBSD). The fix, obviously, is to calculate and use the right timeout value for NFS mount actions. Other actions and timeouts have been left alone. Cherry picked from commit ad876d7a127cf56a3cca11c24ad2b20e1955f82b: > Change-Id: Ic8f013c8c830e33c48bcc6d1b603d6d22a8ba3c5 > Signed-off-by: Jeff Darcy <jdarcy> > Reviewed-on: http://review.gluster.org/12396 > Tested-by: NetBSD Build System <jenkins.org> > Tested-by: Gluster Build System <jenkins.com> > Reviewed-by: Kaleb KEITHLEY <kkeithle> Change-Id: Ic8f013c8c830e33c48bcc6d1b603d6d22a8ba3c5 BUG: 1283679 Signed-off-by: Niels de Vos <ndevos> Reviewed-on: http://review.gluster.org/12663 Tested-by: NetBSD Build System <jenkins.org> Tested-by: Gluster Build System <jenkins.com> Reviewed-by: jiffin tony Thottan <jthottan>
COMMIT: http://review.gluster.org/12664 committed in release-3.7 by Vijay Bellur (vbellur) ------ commit 2035a70bcc19b29a3944c71abc73a9beb90652e2 Author: Niels de Vos <ndevos> Date: Thu Nov 19 15:58:37 2015 +0100 tests: make mount-nfs-auth.t more stable mount-nfs-auth.t has a funky way of restarting the Gluster/NFS service. It is a little racy and does not always work. Disabling and enabling the nfs.disable volume option triggers a restart of the Gluster/NFS service too, and is much simpler. Also adding a little more EXPECT_WITHIN statements to prevent the occasional failures. Cherry picked from commit 0d6f054dbbeffa7190cb41746251c6b77be59a53: > Change-Id: I6765e9f021abbe995dfac00fbfc67298e2ec769c > BUG: 1278476 > Signed-off-by: Niels de Vos <ndevos> > Reviewed-on: http://review.gluster.org/12542 > Tested-by: NetBSD Build System <jenkins.org> > Tested-by: Gluster Build System <jenkins.com> > Reviewed-by: Jeff Darcy <jdarcy> Change-Id: I6765e9f021abbe995dfac00fbfc67298e2ec769c BUG: 1283679 Signed-off-by: Niels de Vos <ndevos> Reviewed-on: http://review.gluster.org/12664 Tested-by: Gluster Build System <jenkins.com> Tested-by: NetBSD Build System <jenkins.org> Reviewed-by: jiffin tony Thottan <jthottan> Reviewed-by: Vijay Bellur <vbellur>
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.7, please open a new bug report. glusterfs-3.7.7 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] https://www.gluster.org/pipermail/gluster-users/2016-February/025292.html [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user