Re: [Gluster-devel] Revert of 56e5fdae (SSL change) - why?

2018-01-07 Thread Atin Mukherjee 
That's true Joe. Ideally the commit should explain the reason of why it was
reverted. I believe Milind is already working on this problem and he should
be able to revive back the patch with the changes required to let all the
tests pass.

On Mon, Jan 8, 2018 at 8:49 AM, Joe Julian  wrote:

> 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 
> wrote:
>
>>
>>
>> On 7 January 2018 at 18:54, Jeff Darcy  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@gluster.org
>>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>>
>>
>>
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
>
> ___
> Gluster-devel mailing 
> listGluster-devel@gluster.orghttp://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Revert of 56e5fdae (SSL change) - why?

2018-01-07 Thread Joe Julian 
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 
> wrote:




On 7 January 2018 at 18:54, Jeff Darcy > 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@gluster.org 
http://lists.gluster.org/mailman/listinfo/gluster-devel




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





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


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

Re: [Gluster-devel] Revert of 56e5fdae (SSL change) - why?

2018-01-07 Thread Atin Mukherjee 
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 
wrote:

>
>
> On 7 January 2018 at 18:54, Jeff Darcy  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@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Revert of 56e5fdae (SSL change) - why?

2018-01-07 Thread Nithya Balachandran 
On 7 January 2018 at 18:54, Jeff Darcy  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@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Weekly Untriaged Bugs

2018-01-07 Thread jenkins 
[...truncated 6 lines...]
https://bugzilla.redhat.com/1531131 / access-control: Connexion refused with 
port 22
https://bugzilla.redhat.com/1529768 / arbiter: Disk size is incorrect according 
to df when an arbiter brick and data brick live on the same server
https://bugzilla.redhat.com/1524325 / bitrot: wrong healing source after upgrade
https://bugzilla.redhat.com/1528983 / build: build: changing verbosity is broken
https://bugzilla.redhat.com/1531987 / build: increment of a boolean expression 
warning
https://bugzilla.redhat.com/1529842 / changelog: Read-only listxattr syscalls 
seem to translate to non-read-only FOPs
https://bugzilla.redhat.com/1529237 / core: File can't access if wrong file 
mode is set in gluster filesystem
https://bugzilla.redhat.com/1528571 / core: glusterd Too many open files
https://bugzilla.redhat.com/1529075 / fuse: Directory listings on fuse mount 
are very slow due to small number of getdents() entries
https://bugzilla.redhat.com/1529085 / fuse: fstat returns ENOENT/ESTALE
https://bugzilla.redhat.com/1529086 / fuse: fstat returns ENOENT/ESTALE
https://bugzilla.redhat.com/1531457 / fuse: hard Link file A to B error if A is 
just created
https://bugzilla.redhat.com/1529088 / fuse: opening a file that is destination 
of rename results in ENOENT errors
https://bugzilla.redhat.com/1529089 / fuse: opening a file that is destination 
of rename results in ENOENT errors
https://bugzilla.redhat.com/1529916 / glusterfind: glusterfind doesn't 
terminate when it fails
https://bugzilla.redhat.com/1529883 / glusterfind: glusterfind is extremely 
slow if there are lots of changes
https://bugzilla.redhat.com/1529992 / glusterfind: glusterfind session 
creation/deletion is inconsistent
https://bugzilla.redhat.com/1524815 / gluster-smb: Writing to samba share stops 
if another gluster node becomes unavailable
https://bugzilla.redhat.com/1529570 / libgfapi: Gfapi segfaults when used in 
multiple threads
https://bugzilla.redhat.com/1525807 / posix: posix: brick process crashes 
during virtual getxattr()
https://bugzilla.redhat.com/1529675 / project-infrastructure: committer name is 
picked up as patch owner in the bugzilla bot update
https://bugzilla.redhat.com/1530111 / project-infrastructure: Logs unavailable 
if a regression run was aborted
https://bugzilla.redhat.com/1526778 / project-infrastructure: The 
gluster-dev-fedora Vagrant box is severely out of date
https://bugzilla.redhat.com/1525850 / rdma: rdma transport may access an 
obsolete item in gf_rdma_device_t->all_mr, and causes glusterfsd/glusterfs 
process crash.
https://bugzilla.redhat.com/1531407 / replicate: dict data type mismatches in 
the logs
https://bugzilla.redhat.com/1528641 / rpc: Brick processes fail to start
https://bugzilla.redhat.com/1527063 / scripts: missing quotes (filenames with 
spaces) get-gfid.sh  generate-gfid-file.sh
https://bugzilla.redhat.com/1529285 / snapshot: snapshot creation not working 
if thin provisioned brick LV is mounted via autofs
https://bugzilla.redhat.com/1529058 / tests: Test case 
./tests/bugs/bug-1371806_1.t is failing
https://bugzilla.redhat.com/1529094 / write-behind: /usr/sbin/glusterfs 
crashing on Red Hat OpenShift Container Platform node
https://bugzilla.redhat.com/1529095 / write-behind: /usr/sbin/glusterfs 
crashing on Red Hat OpenShift Container Platform node
https://bugzilla.redhat.com/1529096 / write-behind: /usr/sbin/glusterfs 
crashing on Red Hat OpenShift Container Platform node
[...truncated 2 lines...]

build.log
Description: Binary data
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Revert of 56e5fdae (SSL change) - why?

2018-01-07 Thread Jeff Darcy 
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 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@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel