Re: [Gluster-devel] netbsd regression logs
Atin Mukherjee amukh...@redhat.com wrote: Is this reproducible in netbsd everytime, if yes I would need a VM to further debug it. nbslave78.cloud.gluster.org Note that it failed a lot of jobs yesterday, I do not know why, but I am not sure the system is the culprit: nbslave7a exhibited the same behavior and is now fine while I did nothing for it. I am guessing that the reason of other failure from tests/geo-rep/georep-setup.t is same. Is it a new regression failure ? Yes, I would say it started on april 30th but it is not ovious to tell as NetBSD regression was already borken by the ENOKEY change. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] netbsd regression logs
On 05/02/2015 09:08 AM, Atin Mukherjee wrote: On 05/02/2015 08:54 AM, Emmanuel Dreyfus wrote: Pranith Kumar Karampuri pkara...@redhat.com wrote: Seems like glusterd failure from the looks of it: +glusterd folks. Running tests in file ./tests/basic/cdc.t volume delete: patchy: failed: Another transaction is in progress for patchy. Please try again after sometime. [18:16:40] ./tests/basic/cdc.t .. not ok 52 This is a volume stop that fails. Logs says a lock is held by an UUID which happeens to be the volume's own UUID. I tried git bisect and it seems to be related to http://review.gluster.org/9918 but I am not completely sure (I may have botched by git bisect) I'm looking into this. Looking at the logs, here is the findings: - gluster volume stop got timed out at cli because of which cmd_history.log didn't capture it. - glusterd acquired the volume lock in volume stop but didn't release it somehow as gluster v delete failed saying another transaction is in progress - For gluster volume stop transaction I could see glusterd_nfssvc_stop was triggered but after that it didn't log anything for almost two minutes, but catching point here is by this time volinfo-status should have been marked as stopped and persisted in the disk, but gluster v info didn't reflect the same. Is this reproducible in netbsd everytime, if yes I would need a VM to further debug it. I am guessing that the reason of other failure from tests/geo-rep/georep-setup.t is same. Is it a new regression failure ? ~Atin -- ~Atin ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] netbsd regression logs
Emmanuel Dreyfus m...@netbsd.org wrote: Note that it failed a lot of jobs yesterday, I do not know why, but I am not sure the system is the culprit: nbslave7a exhibited the same behavior and is now fine while I did nothing for it. I think it is git.gluster.org that misbehaved: I started /autobuild/autobuild.sh on nbslave78 and it seems fine. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] netbsd regression logs
On 05/02/2015 08:54 AM, Emmanuel Dreyfus wrote: Pranith Kumar Karampuri pkara...@redhat.com wrote: Seems like glusterd failure from the looks of it: +glusterd folks. Running tests in file ./tests/basic/cdc.t volume delete: patchy: failed: Another transaction is in progress for patchy. Please try again after sometime. [18:16:40] ./tests/basic/cdc.t .. not ok 52 This is a volume stop that fails. Logs says a lock is held by an UUID which happeens to be the volume's own UUID. I tried git bisect and it seems to be related to http://review.gluster.org/9918 but I am not completely sure (I may have botched by git bisect) I'm looking into this. -- ~Atin ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] netbsd regression logs
Pranith Kumar Karampuri pkara...@redhat.com wrote: Seems like glusterd failure from the looks of it: +glusterd folks. Running tests in file ./tests/basic/cdc.t volume delete: patchy: failed: Another transaction is in progress for patchy. Please try again after sometime. [18:16:40] ./tests/basic/cdc.t .. not ok 52 This is a volume stop that fails. Logs says a lock is held by an UUID which happeens to be the volume's own UUID. I tried git bisect and it seems to be related to http://review.gluster.org/9918 but I am not completely sure (I may have botched by git bisect) -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] netbsd regression logs
Seems like glusterd failure from the looks of it: +glusterd folks. Running tests in file ./tests/basic/cdc.t volume delete: patchy: failed: Another transaction is in progress for patchy. Please try again after sometime. [18:16:40] ./tests/basic/cdc.t .. not ok 52 not ok 53 Got Started instead of Stopped not ok 54 not ok 55 Failed 4/55 subtests [18:16:40] Pranith On 05/02/2015 01:23 AM, Emmanuel Dreyfus wrote: Justin Clift jus...@gluster.org wrote: They are archived, in /archives/logs/ on the regressions VM. It's just that you have to get them through sftp. Is it easy to add web access for them? It was really easy: http://nbslave76.cloud.gluster.org/archives/logs/glusterfs-logs-20150501182952.tgz Now there is the script in jenkins to tweak to give the URL instead of host:/path I go offline, feel free to beat me at fixing this. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] netbsd regression logs
On 1 May 2015, at 16:08, Emmanuel Dreyfus m...@netbsd.org wrote: Pranith Kumar Karampuri pkara...@redhat.com wrote: I was not able to re-create glupy failure. I see that netbsd is not archiving logs like the linux regression. Do you mind adding that one? I think kaushal and Vijay did this for Linux regressions, so CC them. They are archived, in /archives/logs/ on the regressions VM. It's just that you have to get them through sftp. Is it easy to add web access for them? (eg nginx or whatever) We have the nginx rule for the CentOS ones around somewhere if it'd help? + Justin -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] netbsd regression logs
Justin Clift jus...@gluster.org wrote: They are archived, in /archives/logs/ on the regressions VM. It's just that you have to get them through sftp. Is it easy to add web access for them? It was really easy: http://nbslave76.cloud.gluster.org/archives/logs/glusterfs-logs-20150501182952.tgz Now there is the script in jenkins to tweak to give the URL instead of host:/path I go offline, feel free to beat me at fixing this. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] netbsd regression logs
Justin Clift jus...@gluster.org wrote: Is it easy to add web access for them? (eg nginx or whatever) NetBSD has a built-in simple web server but I have never set it up. I will look at it once I will have investigated the cdc.t regression. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
