Re: Revert of 56e5fdae (SSL change) - why?

[Joe Julian <joe@xxxxxxxxxxxxxxxx>]

The point is, I believe, that one shouldn't have to go digging through external resources to find out why a commit exists. Please ensure the commit message has adequate accurate information.

On 01/07/2018 07:11 PM, Atin Mukherjee wrote:

Also please refer http://lists.gluster.org/pipermail/gluster-devel/2017-December/054103.html . Some of the tests like ssl-cipher.t, trash.t were failing frequently in brick multiplexing enabled regression jobs. When I reverted this patch, I couldn't reproduce any of those test failures.

On Mon, Jan 8, 2018 at 8:36 AM, Nithya Balachandran <nbalacha@xxxxxxxxxx> wrote:

On 7 January 2018 at 18:54, Jeff Darcy <jeff@xxxxxxxxxx> wrote:

There's no explanation, or reference to one, in the commit message. In the comments, there's a claim that seems a bit exaggerated.

> This is causing almost all the regressions to fail. durbaility-off.t is the most affected test.

This patch does seem to be the cause. Running this test in a loop on my local system with the patch caused it to fail several times (it is an intermittent failure). The test passed every time after I tried the same after reverting the patch. When it fails, it is because the mount process does not connect to all bricks.

This patch was merged on December 13. Regressions have passed many times since then. If almost all regressions have started failing recently, I suggest we look for a more recent cause. For example, if this was collateral damage from debugging the dict-change issue, then the patch should be reinstated (which I see has not been done). Alternatively, is the above supposed to mean that this patch has been observed to cause *occasional* failures in many other tests? If so, which tests and when? There's no way to search for these in Gerrit or Jenkins. If specific logs or core-dump analyses point toward this conclusion and the subsequent action, then it would be very helpful for those to be brought forward so we can debug the underlying problem. That's likely to be hard enough without trying to do it blind.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel

_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel

_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel

_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel