Re: [Gluster-infra] New workflow proposal for glusterfs repo
On Wed, Jun 12, 2019, 1:56 PM Atin Mukherjee wrote: > > > On Wed, 12 Jun 2019 at 18:04, Amar Tumballi Suryanarayan < > atumb...@redhat.com> wrote: > >> >> Few bullet points: >> >> * Let smoke job sequentially for below, and if successful, in parallel >> for others. >> - Sequential: >> -- clang-format check >> -- compare-bugzilla-version-git-branch >> -- bugzilla-post >> -- comment-on-issue >> -- fedora-smoke (mainly don't want warning). >> > > +1 > > - Parallel >>-- all devrpm jobs >>-- 32bit smoke >>-- freebsd-smoke >>-- smoke >>-- strfmt_errors >>-- python-lint, and shellcheck. >> > > I’m sure there must be a reason but would like to know that why do they > need to be parallel? Can’t we have them sequentially to have similar > benefits of the resource utilisation like above? Or are all these > individual jobs are time consuming such that having them sequentially will > lead the overall smoke job to consume much longer? > > >> * Remove Verified flag. No point in one more extra button which users >> need to click, anyways CentOS regression is considered as 'Verification'. >> > The requirement of verified flag by patch owner for regression to run was added because the number of Jenkins machines we had were few and patches being uploaded were many. >> * In a normal flow, let CentOS regression which is running after >> 'Verified' vote, be triggered on first 'successful' +1 reviewed vote. >> > > As I believe some reviewers/maintainers (including me) would like to see > the regression vote to put a +1/+2 in most of the patches until and unless > they are straight forward ones. So although with this you’re reducing the > burden of one extra click from the patch owner, but on the other way you’re > introducing the same burden on the reviewers who would like to check the > regression vote. IMHO, I don’t see much benefits in implementing this. > Agree with Atin here. Burden should be on machines before people. Reviewers prefer to look at patches that have passed regression. In github heketi, we have configured regression to run on all patches that are submitted by heketi developer group. If such configuration is possible in gerrit+Jenkins, we should definitely do it that way. For patches that are submitted by someone outside of the developer group, a maintainer should verify that the patch doesn't do anything harmful and mark the regression to run. Talur > >> * For those patches which got pushed to system to just 'validate' >> behavior, to run sample tests, WIP patches, continue to support 'recheck >> centos' comment message, so we can run without any vote. Let it not be the >> norm. >> >> >> With this, I see that we can reduce smoke failures utilize 90% less >> resources for a patch which would fail smoke anyways. (ie, 95% of the smoke >> failures would be caught in first 10% of the resource, and time). >> >> Also we can reduce number of regression running, as review is mandatory >> to run regression. >> >> These are just suggestions, happy to discuss more on these. >> >> -Amar >> >> >> >> ___ >> Gluster-infra mailing list >> Gluster-infra@gluster.org >> https://lists.gluster.org/mailman/listinfo/gluster-infra > > -- > - Atin (atinm) > ___ > Gluster-infra mailing list > Gluster-infra@gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-infra ___ Gluster-infra mailing list Gluster-infra@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Where to request for adding versions in Bugzilla
On Mon, May 15, 2017 at 5:49 AM, Vijay Bellur wrote: > > > On Sun, May 14, 2017 at 8:04 PM, Vijay Bellur wrote: >> >> On 05/14/2017 04:02 PM, Raghavendra Talur wrote: >>> >>> Hi All, >>> >>> I need 3.10.1 and 3.10.2 versions added to Glusterfs product. How do I do >>> it? >>> >> >> You would need to file a request with Red Hat's bugzilla admin. I will >> mail details about the process offline. >> > > I have forwarded you details. However I remember a discussion on not adding > bz versions for minor updates in 3.8.x. The expectation was that users would > provide details about the exact version in the bug description. Do we want > to follow a similar process for 3.10? Thanks Vijay! May be this is why Shyam hasn't created 3.10.1 version already? If so, I will not send this request. > > Thanks, > Vijay ___ Gluster-infra mailing list Gluster-infra@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] Where to request for adding versions in Bugzilla
Hi All, I need 3.10.1 and 3.10.2 versions added to Glusterfs product. How do I do it? Thanks, Raghavendra Talur ___ Gluster-infra mailing list Gluster-infra@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Is anyone else having trouble authenticating with review.gluster.org over ssh?
On Sun, Apr 16, 2017 at 9:07 PM, Raghavendra Talur wrote: > I am not able to login even after specifying the key file > > $ ssh -T -vvv -i ~/.ssh/gluster raghavendra-ta...@git.gluster.org > OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017 > debug1: Reading configuration data /home/rtalur/.ssh/config > debug1: Reading configuration data /etc/ssh/ssh_config > debug3: /etc/ssh/ssh_config line 56: Including file > /etc/ssh/ssh_config.d/05-redhat.conf depth 0 > debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf > debug1: /etc/ssh/ssh_config.d/05-redhat.conf line 2: include > /etc/crypto-policies/back-ends/openssh.txt matched no files > debug1: /etc/ssh/ssh_config.d/05-redhat.conf line 8: Applying options for * > debug1: auto-mux: Trying existing master > debug1: Control socket > "/tmp/ssh_mux_git.gluster.org_22_raghavendra-talur" does not exist > debug2: resolving "git.gluster.org" port 22 > debug2: ssh_connect_direct: needpriv 0 > debug1: Connecting to git.gluster.org [8.43.85.171] port 22. > debug1: Connection established. > debug1: identity file /home/rtalur/.ssh/gluster type 1 > debug1: key_load_public: No such file or directory > debug1: identity file /home/rtalur/.ssh/gluster-cert type -1 > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_7.4 > ssh_exchange_identification: Connection closed by remote host Confirmed with Pranith that he is facing same issue. Nigel/Misc, Please have a look. > > Thanks, > Raghavendra Talur ___ Gluster-infra mailing list Gluster-infra@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] Is anyone else having trouble authenticating with review.gluster.org over ssh?
I am not able to login even after specifying the key file $ ssh -T -vvv -i ~/.ssh/gluster raghavendra-ta...@git.gluster.org OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017 debug1: Reading configuration data /home/rtalur/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug3: /etc/ssh/ssh_config line 56: Including file /etc/ssh/ssh_config.d/05-redhat.conf depth 0 debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf debug1: /etc/ssh/ssh_config.d/05-redhat.conf line 2: include /etc/crypto-policies/back-ends/openssh.txt matched no files debug1: /etc/ssh/ssh_config.d/05-redhat.conf line 8: Applying options for * debug1: auto-mux: Trying existing master debug1: Control socket "/tmp/ssh_mux_git.gluster.org_22_raghavendra-talur" does not exist debug2: resolving "git.gluster.org" port 22 debug2: ssh_connect_direct: needpriv 0 debug1: Connecting to git.gluster.org [8.43.85.171] port 22. debug1: Connection established. debug1: identity file /home/rtalur/.ssh/gluster type 1 debug1: key_load_public: No such file or directory debug1: identity file /home/rtalur/.ssh/gluster-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.4 ssh_exchange_identification: Connection closed by remote host Thanks, Raghavendra Talur ___ Gluster-infra mailing list Gluster-infra@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] what does G_BROKEN_FILENAMES=1 in console output mean?
I am seeing a new env var in console output[1] of jenkins, G_BROKEN_FILENAMES, what does this mean? [1] https://build.gluster.org/job/centos6-regression/3819/consoleFull Thanks, Raghavendra Talur ___ Gluster-infra mailing list Gluster-infra@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] Request to provide PASS flags to a patch in gerrit
Hi All, We have a test [1] which is causing hangs in NetBSD. We have not been able to debug the issue yet. It could be because the bash script does not comply with posix guidelines or that there is a bug in the brick code. However, as we have 3.9 merge deadline tomorrow this is causing the test pipeline to grow a lot and needing manual intervention. I recommend we disable this test for now. I request Kaushal to provide pass flags to the patch [2] for faster merge. [1] ./tests/features/lock_revocation.t [2] http://review.gluster.org/#/c/15374/ Thanks, Raghavendra Talur ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] [Gluster-devel] tests/basic/op_errnos.t failure
Nigel/Misc, Could you please look into this? slave29 does not seem to have a xfs formatted backend for tests. Thanks, Raghavendra Talur On Tue, Jul 12, 2016 at 6:41 PM, Avra Sengupta wrote: > Atin, > > I am not sure about the docker containers, but both the failures you > mentioned are in slave29, which as Talur explained is missing the > appropriate backend filesystem. Owing to this, op-errno.t is just the tip > of the iceberg, and every other test that uses lvm will fail in this > particular slave will fail too. > > Talur, > Thanks for looking into it. It is indeed strange this. I checked the dmesg > and the /var/log/messages in this slave and I couldn't find any relevant > log. > > > On 07/12/2016 05:29 PM, Raghavendra Talur wrote: > > I checked the machine. > > Here is the df -hT output > [jenkins@slave29 ~]$ cat /etc/fstab > # Accessible filesystems, by reference, are maintained under '/dev/disk' > # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info > # > /dev/xvda1 / ext3 > defaults,noatime,barrier=0 1 1 > tmpfs /dev/shmtmpfs defaults0 0 > devpts /dev/ptsdevpts gid=5,mode=620 0 0 > sysfs /syssysfs defaults0 0 > proc/proc procdefaults0 0 > #/dev/xvdc1 noneswapsw 0 0 > > > We don't see a xfs device mounted at /d and / is of type ext3 which does > not support fallocate. The uptime of the machine is 73 days though. I don't > know how the /d xfs partition vanished. > > On Tue, Jul 12, 2016 at 4:54 PM, Atin Mukherjee < > amukh...@redhat.com> wrote: > >> >> https://build.gluster.org/job/rackspace-regression-2GB-triggered/22156/consoleFull >> - another failure >> >> On Tue, Jul 12, 2016 at 4:42 PM, Atin Mukherjee < >> amukh...@redhat.com> wrote: >> >>> >>> >>> On Tue, Jul 12, 2016 at 4:36 PM, Avra Sengupta < >>> aseng...@redhat.com> wrote: >>> >>>> Hi Atin, >>>> >>>> Please check the testcase result in the console. It clearly states the >>>> reason of the failure. A quick search of 30815, as shown in the testcase >>>> shows that the error that is generated is a thinp issue, and we can see >>>> fallocate failing and lvm not properly being setup in the environment. >>>> >>> >>> While this is valid for my docker containers, I am just wondering why >>> did this happen in jenkins slave? >>> >>> >>>> Regards, >>>> Avra >>>> >>>> P.S Here are the logs from the console stating so. >>>> >>>> *02:50:34* [09:50:34] Running tests in file >>>> ./tests/basic/op_errnos.t*02:50:41* fallocate: >>>> /d/backends/patchy_snap_vhd: fallocate failed: Operation not >>>> supported*02:50:41* losetup: /d/backends/patchy_snap_vhd: warning: file >>>> smaller than 512 bytes, the loop device maybe be useless or invisible for >>>> system tools.*02:50:41* Device /d/backends/patchy_snap_loop not found >>>> (or ignored by filtering).*02:50:41* Device /d/backends/patchy_snap_loop >>>> not found (or ignored by filtering).*02:50:41* Unable to add physical >>>> volume '/d/backends/patchy_snap_loop' to volume group >>>> 'patchy_snap_vg_1'.*02:50:41* Volume group "patchy_snap_vg_1" not >>>> found*02:50:41* Cannot process volume group patchy_snap_vg_1*02:50:42* >>>> Volume group "patchy_snap_vg_1" not found*02:50:42* Cannot process >>>> volume group patchy_snap_vg_1*02:50:42* /dev/patchy_snap_vg_1/brick_lvm: >>>> No such file or directory*02:50:42* Usage: mkfs.xfs*02:50:42* /* blocksize >>>> */ [-b log=n|size=num]*02:50:42* /* data subvol */ [-d >>>> agcount=n,agsize=n,file,name=xxx,size=num,*02:50:42* >>>> (sunit=value,swidth=value|su=num,sw=num),*02:50:42* >>>> sectlog=n|sectsize=num*02:50:42* /* inode size */ [-i >>>> log=n|perblock=n|size=num,maxpct=n,attr=0|1|2,*02:50:42* >>>> projid32bit=0|1]*02:50:42* /* log subvol */ [-l >>>> agnum=n,internal,size=num,logdev=xxx,version=n*02:50:42* >>>> sunit=value|su=num,sectlog=n|sectsize=num,*02:50:42* >>>>
Re: [Gluster-infra] NetBSD machine required to debug a core
On Thu, May 12, 2016 at 7:48 PM, Kaushal M wrote: > On Thu, May 12, 2016 at 6:02 PM, Raghavendra Talur > wrote: > > slave26.cloud.gluster.org is taken down for you. > > please update here when done. > > Isn't this a CentOS machine? > I blame it on lack of caffeine and bad headache :-/ I have brought back slave26.cloud.gluster.org and taken down nbslave7j.cloud.gluster.org for Ravi. > > > > Thanks, > > Raghavendra Talur > > > > > > On Wed, May 11, 2016 at 2:49 PM, Ravishankar N > > wrote: > >> > >> Hello, > >> > >> I would need a NetBSD machine to debug a crash > >> > https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/16749/consoleFull > >> > >> The test that is failing is a .t that I have written as a part of the > >> patch against which the regression was triggered. > >> > >> Thanks, > >> > >> Ravi > >> > >> ___ > >> Gluster-infra mailing list > >> Gluster-infra@gluster.org > >> http://www.gluster.org/mailman/listinfo/gluster-infra > > > > > > > > ___ > > Gluster-infra mailing list > > Gluster-infra@gluster.org > > http://www.gluster.org/mailman/listinfo/gluster-infra > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] NetBSD machine required to debug a core
slave26.cloud.gluster.org is taken down for you. please update here when done. Thanks, Raghavendra Talur On Wed, May 11, 2016 at 2:49 PM, Ravishankar N wrote: > Hello, > > I would need a NetBSD machine to debug a crash > https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/16749/consoleFull > > The test that is failing is a .t that I have written as a part of the > patch against which the regression was triggered. > > Thanks, > > Ravi > > ___ > Gluster-infra mailing list > Gluster-infra@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-infra > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] LVM operations on some slaves taking a lot of time
I saw snapshot tests taking a lot of time of slave22.cloud.gluster.org and on further investigation I found that it was lvm and its commands that were taking time. Link: https://build.gluster.org/job/rackspace-regression-2GB-triggered/19891/consoleFull Ignore if this is a one off case. If this repeats we need to see what is wrong with the slave. Thanks, Raghavendra Talur ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] Request to add more maintainers for DISTAF
Hi All, We have now merged the first patch for Distaf libs and Distaf tests in Gluster git repo.[1] M S Vishwanath already has merge rights on gerrit for Gluster repo. I would like to propose Shwetha and Jonathan as additional maintainers for Distaf related code. If no one has any objections I request infra team to add them to maintainers group. [1]: http://review.gluster.org/#/c/13853/ Thanks, Raghavendra Talur ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] nbslave7g.cloud.gluster.org assigned to anoop c s for debugging
___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] [Gluster-devel] Gerrit trigger connection to jenkins not working
Thanks Kaushal! On Wed, Mar 16, 2016 at 11:54 AM, Kaushal M wrote: > Fixed now. Check my reply to Kaleb's earlier mail for the details. > > On Wed, Mar 16, 2016 at 11:07 AM, Raghavendra Talur > wrote: > > Root cause: I see the following error when I do "test connection" > > Connection error : com.jcraft.jsch.JSchException: > > java.net.NoRouteToHostException: No route to host > > > > > > On Wed, Mar 16, 2016 at 10:57 AM, Raghavendra Talur > > wrote: > >> > >> Hi All, > >> > >> I see that jenkins isn't getting any triggers from gerrit. This includes > >> patch set update trigger, so basically no patch is automatically > tested. I > >> am looking into it. Will update in this thread. > >> > >> For anything critical and urgent, please mail in gluster-devel asking > >> jenkins maintainers to trigger build from you. > >> > >> Thanks, > >> Raghavendra Talur > > > > > > > > ___ > > Gluster-devel mailing list > > gluster-de...@gluster.org > > http://www.gluster.org/mailman/listinfo/gluster-devel > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Gerrit trigger connection to jenkins not working
Root cause: I see the following error when I do "test connection" Connection error : com.jcraft.jsch.JSchException: java.net.NoRouteToHostException: No route to host On Wed, Mar 16, 2016 at 10:57 AM, Raghavendra Talur wrote: > Hi All, > > I see that jenkins isn't getting any triggers from gerrit. This includes > patch set update trigger, so basically no patch is automatically tested. I > am looking into it. Will update in this thread. > > For anything critical and urgent, please mail in gluster-devel asking > jenkins maintainers to trigger build from you. > > Thanks, > Raghavendra Talur > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] Gerrit trigger connection to jenkins not working
Hi All, I see that jenkins isn't getting any triggers from gerrit. This includes patch set update trigger, so basically no patch is automatically tested. I am looking into it. Will update in this thread. For anything critical and urgent, please mail in gluster-devel asking jenkins maintainers to trigger build from you. Thanks, Raghavendra Talur ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Code-Review+2 and Verified+1 cause multiple retriggers on Jenkins
On Fri, Mar 4, 2016 at 6:13 PM, Raghavendra Talur wrote: > > > On Thu, Feb 4, 2016 at 7:13 PM, Niels de Vos wrote: > >> On Thu, Feb 04, 2016 at 04:15:16PM +0530, Raghavendra Talur wrote: >> > On Thu, Feb 4, 2016 at 4:13 PM, Niels de Vos wrote: >> > >> > > On Thu, Feb 04, 2016 at 03:34:05PM +0530, Raghavendra Talur wrote: >> > > > Hi, >> > > > >> > > > We recently changed the jenkins builds to be triggered on the >> following >> > > > triggers. >> > > > >> > > > 1. Verified+1 >> > > > 2. Code-review+2 >> > > > 3. recheck (netbsd|centos|smoke) >> > > > >> > > > There is a bug in 1 and 2. >> > > > >> > > > Multiple triggers of 1 or 2 would result in re-runs even when not >> > > intended. >> > > > >> > > > I would like to replace 1 and 2 with a comment "run-all-regression" >> or >> > > > something like that. >> > > > Thoughts? >> > > >> > > Maybe starting regressions on Code-Review +1 (or +2) only? >> > > >> > >> > Multiple code-reviews would do multiple triggers. Won't work. >> >> How can we make this to work, without the need of providing magic >> comments? >> > > I investigated but couldn't find a way to make it work. Discussed with > Kaushal and we feel it should be ok to go with a "check all" comment for > initial regression run and deprecate Code-Review+2 and Verified+1 triggers. > > I would like to go ahead and do it as the build queue is increasing again > just because of Code-Review+2's given just before a patch is merged; they > don't serve any purpose. > I have for now just removed trigger for code-review. Trigger for verified+1 remains as is. No new trigger on comments have been added. >> Niels >> > > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Code-Review+2 and Verified+1 cause multiple retriggers on Jenkins
On Thu, Feb 4, 2016 at 7:13 PM, Niels de Vos wrote: > On Thu, Feb 04, 2016 at 04:15:16PM +0530, Raghavendra Talur wrote: > > On Thu, Feb 4, 2016 at 4:13 PM, Niels de Vos wrote: > > > > > On Thu, Feb 04, 2016 at 03:34:05PM +0530, Raghavendra Talur wrote: > > > > Hi, > > > > > > > > We recently changed the jenkins builds to be triggered on the > following > > > > triggers. > > > > > > > > 1. Verified+1 > > > > 2. Code-review+2 > > > > 3. recheck (netbsd|centos|smoke) > > > > > > > > There is a bug in 1 and 2. > > > > > > > > Multiple triggers of 1 or 2 would result in re-runs even when not > > > intended. > > > > > > > > I would like to replace 1 and 2 with a comment "run-all-regression" > or > > > > something like that. > > > > Thoughts? > > > > > > Maybe starting regressions on Code-Review +1 (or +2) only? > > > > > > > Multiple code-reviews would do multiple triggers. Won't work. > > How can we make this to work, without the need of providing magic > comments? > I investigated but couldn't find a way to make it work. Discussed with Kaushal and we feel it should be ok to go with a "check all" comment for initial regression run and deprecate Code-Review+2 and Verified+1 triggers. I would like to go ahead and do it as the build queue is increasing again just because of Code-Review+2's given just before a patch is merged; they don't serve any purpose. > > Niels > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] How to use jenkins cli for editing job
Hi, I changed the worker thread count for gerrit-trigger plugin send worker to 3 from 1. This was because there were warning in jenkins home page saying the queue has 2400 events and suggested to increase worker threads. As Niels had suggested before, I tried performing the same update using the cli. I was not able to use it though, kept getting "resource has moved" error. Could someone else try too and also write a simple doc on how to use the cli tool? Thanks, Raghavendra ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] review.gluster.org not working
On Feb 27, 2016 9:04 PM, "Amye Scavarda" wrote: > > On Fri, Feb 26, 2016 at 9:24 PM, Raghavendra Talur wrote: > > > > On Feb 26, 2016 11:23 PM, "Raghavendra Talur" wrote: > >> > >> > >> > >> On Fri, Feb 26, 2016 at 6:29 PM, Kaleb Keithley > >> wrote: > >>> > >>> > >>> > >>> - Original Message - > >>> > From: "Raghavendra Talur" > >>> > > >>> > Most likely it looks like disk is full. Someone please have a look at > >>> > it. > >>> > > >>> > >>> Someone who? Misc is on holiday IIRC. Who else has access? > >> > >> > >> I think it is only Vijay and Kaushal other than misc who have access. > > > > I spoke to Kaushal over phone. He does not have access either. Adding misc > > hoping to catch his attention. > > > >> > >>> > >>> > >>> Why do we think running our own gerrit and jenkins is a good thing? (When > >>> we could be using the CentOS gerrit and jenkins?) > >> > >> > >> That discussion did happen in Devconf and will be discussed in > >> gluster-devel is what I understand. We should wait for people to put across > >> pros and cons for that. > >> Personally, > >> 1. I would want infra which has a large enough team to have a 24/7 > >> monitoring.(As ndevos suggested, if we form a bigger group we can do so with > >> our current setup.) > >> 2. Have control over gerrit settings so that we can decide what do we mean > >> by trivial patches, and what patches carry over review comments etc. > >> > >> > >>> > >>> > >>> (Yes, I am feeling snarky.) > >> > >> > >> Understandable, given how easily our infra breaks. We who are in > >> gluster-infra group have to come up with a solution too. > >> > >>> > >>> -- > >>> > >>> Kaleb > >>> ___ > >>> Gluster-infra mailing list > >>> Gluster-infra@gluster.org > >>> http://www.gluster.org/mailman/listinfo/gluster-infra > >> > >> > > > > > > ___ > > Gluster-infra mailing list > > Gluster-infra@gluster.org > > http://www.gluster.org/mailman/listinfo/gluster-infra > > Misc is indeed out of the office, but he will return on Monday. > > In the meantime, can we put this on the list of documented > infrastructure pieces that more than one person needs access to - so > that we can start forming that effective infra team? Part of the > challenge is that the responsibilities haven't been clear, so getting > people to volunteer to assist is not helpful. > > The conversation about CentOS's CI/CD is still ongoing, and in no way > do I want to dissuade Kaleb's snarky yet helpful suggestions. Keep 'em > coming. +1 to everything. Update : the site is working now. Not sure about who fixed it or what fixed it. > - amye > > -- > Amye Scavarda | a...@redhat.com | Gluster Community Lead ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] review.gluster.org not working
On Feb 26, 2016 11:23 PM, "Raghavendra Talur" wrote: > > > > On Fri, Feb 26, 2016 at 6:29 PM, Kaleb Keithley wrote: >> >> >> >> - Original Message - >> > From: "Raghavendra Talur" >> > >> > Most likely it looks like disk is full. Someone please have a look at it. >> > >> >> Someone who? Misc is on holiday IIRC. Who else has access? > > > I think it is only Vijay and Kaushal other than misc who have access. I spoke to Kaushal over phone. He does not have access either. Adding misc hoping to catch his attention. > >> >> >> Why do we think running our own gerrit and jenkins is a good thing? (When we could be using the CentOS gerrit and jenkins?) > > > That discussion did happen in Devconf and will be discussed in gluster-devel is what I understand. We should wait for people to put across pros and cons for that. > Personally, > 1. I would want infra which has a large enough team to have a 24/7 monitoring.(As ndevos suggested, if we form a bigger group we can do so with our current setup.) > 2. Have control over gerrit settings so that we can decide what do we mean by trivial patches, and what patches carry over review comments etc. > > >> >> >> (Yes, I am feeling snarky.) > > > Understandable, given how easily our infra breaks. We who are in gluster-infra group have to come up with a solution too. > >> >> -- >> >> Kaleb >> ___ >> Gluster-infra mailing list >> Gluster-infra@gluster.org >> http://www.gluster.org/mailman/listinfo/gluster-infra > > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] review.gluster.org not working
On Fri, Feb 26, 2016 at 6:29 PM, Kaleb Keithley wrote: > > > - Original Message - > > From: "Raghavendra Talur" > > > > Most likely it looks like disk is full. Someone please have a look at it. > > > > Someone who? Misc is on holiday IIRC. Who else has access? > I think it is only Vijay and Kaushal other than misc who have access. > > Why do we think running our own gerrit and jenkins is a good thing? (When > we could be using the CentOS gerrit and jenkins?) > That discussion did happen in Devconf and will be discussed in gluster-devel is what I understand. We should wait for people to put across pros and cons for that. Personally, 1. I would want infra which has a large enough team to have a 24/7 monitoring.(As ndevos suggested, if we form a bigger group we can do so with our current setup.) 2. Have control over gerrit settings so that we can decide what do we mean by trivial patches, and what patches carry over review comments etc. > > (Yes, I am feeling snarky.) > Understandable, given how easily our infra breaks. We who are in gluster-infra group have to come up with a solution too. > -- > > Kaleb > ___ > Gluster-infra mailing list > Gluster-infra@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-infra > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] review.gluster.org not working
Most likely it looks like disk is full. Someone please have a look at it. ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] Restricted trigger server for centos and netbsd regression to review.gluster.org
Hi, After misc fixed ssl and cert issues on gerrit, jenkins now connects to review.gluster.org using both the configurations. 1. old one which has name review.gluster.org 2. new one which has review.gluster.org_for_smoke_builds 2 was configured by ndevos for CI work I guess. CentOS and NetBSD regression jobs were configured to take events from any server and this resulted in duplicate/concurrent runs for each event from gerrit. I have changed the event trigger on these jobs to use only review.gluster.org. Terminated some of the duplicate builds on jenkins for the same reason. Thanks, Raghavendra Talur ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] Gerrit trigger isn't working
Hi All, The last triggered builds in jenkins show the following time for me Feb 6, 2016 1:24 PM Current time as per jenkins is Feb 7, 2016 12:45:50 AM I am guessing some change happened about 12 hours ago which caused gerrit trigger to stop working. I have started a few jobs using "build with parameters" option and it is working fine. Could someone have a look.. Thanks, Raghavendra Talur ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] Gerrit is not responding
$subject, can someone have a look at it? ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Code-Review+2 and Verified+1 cause multiple retriggers on Jenkins
On Thu, Feb 4, 2016 at 4:13 PM, Niels de Vos wrote: > On Thu, Feb 04, 2016 at 03:34:05PM +0530, Raghavendra Talur wrote: > > Hi, > > > > We recently changed the jenkins builds to be triggered on the following > > triggers. > > > > 1. Verified+1 > > 2. Code-review+2 > > 3. recheck (netbsd|centos|smoke) > > > > There is a bug in 1 and 2. > > > > Multiple triggers of 1 or 2 would result in re-runs even when not > intended. > > > > I would like to replace 1 and 2 with a comment "run-all-regression" or > > something like that. > > Thoughts? > > Maybe starting regressions on Code-Review +1 (or +2) only? > Multiple code-reviews would do multiple triggers. Won't work. > > Niels > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] Code-Review+2 and Verified+1 cause multiple retriggers on Jenkins
Hi, We recently changed the jenkins builds to be triggered on the following triggers. 1. Verified+1 2. Code-review+2 3. recheck (netbsd|centos|smoke) There is a bug in 1 and 2. Multiple triggers of 1 or 2 would result in re-runs even when not intended. I would like to replace 1 and 2 with a comment "run-all-regression" or something like that. Thoughts? Thanks Raghavendra Talur ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Different version of run-tests.sh in jenkin slaves?
On Thu, Jan 28, 2016 at 12:10 PM, Atin Mukherjee wrote: > > > On 01/28/2016 12:00 PM, Raghavendra Talur wrote: > > Ok, RCA: > > > > In NetBSD cores are being generated in /d/backends/*/*.core > > run-tests.sh looks only for "/core*" when looking for cores. > > > > So, at the end of test run when regression.sh looks for core everywhere, > > it finds one and errors out. > So does that mean we never analyzed any core reported by NetBSD > regression failure? That's strange. > I wonder when these changes were done. Manu, Where do I find config in NetBSD which decides which location to dump core in? Any particular reason you added /d/backends/*/*.core to list of path to search for core? > > > Should think of a solution which is generic. Will update. > > > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Different version of run-tests.sh in jenkin slaves?
Ok, RCA: In NetBSD cores are being generated in /d/backends/*/*.core run-tests.sh looks only for "/core*" when looking for cores. So, at the end of test run when regression.sh looks for core everywhere, it finds one and errors out. Should think of a solution which is generic. Will update. On Thu, Jan 28, 2016 at 11:37 AM, Raghavendra Talur wrote: > > > On Thu, Jan 28, 2016 at 11:17 AM, Atin Mukherjee > wrote: > >> Are we running a different version of run-tests.sh in jenkin slaves. The >> reason of suspection is beacuse in last couple of runs [1] & [2] in >> NetBSD I am seeing no failures apart from bad tests but the regression >> voted failure and I can not make out any valid reason out of it. >> >> [1] >> >> https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/13756/consoleFull >> [2] >> >> https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/13755/consoleFull > > > > I checked the slave machine now. > regression.sh file is different but the run-tests.sh script is same. > > A wild guess here, is it possible that the core generation takes time and > when we check for a core right after a test is run it is not present yet? > Does anyone know how to work around that? > > >> >> ~Atin >> ___ >> Gluster-infra mailing list >> Gluster-infra@gluster.org >> http://www.gluster.org/mailman/listinfo/gluster-infra >> > > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Different version of run-tests.sh in jenkin slaves?
On Thu, Jan 28, 2016 at 11:17 AM, Atin Mukherjee wrote: > Are we running a different version of run-tests.sh in jenkin slaves. The > reason of suspection is beacuse in last couple of runs [1] & [2] in > NetBSD I am seeing no failures apart from bad tests but the regression > voted failure and I can not make out any valid reason out of it. > > [1] > > https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/13756/consoleFull > [2] > > https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/13755/consoleFull I checked the slave machine now. regression.sh file is different but the run-tests.sh script is same. A wild guess here, is it possible that the core generation takes time and when we check for a core right after a test is run it is not present yet? Does anyone know how to work around that? > > ~Atin > ___ > Gluster-infra mailing list > Gluster-infra@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-infra > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] Netbsd regression failing after clean run
Hi all, Over the weekend I have seen instances of tests (mine and ndevos) where ret is equal to 1 from regression.sh. I checked for core on the slave and could not find any. I wasn't able to find the root cause. Will debug more tomorrow. Did any configuration change on netbsd machines? Thanks Raghavendra Talur ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] Removed "clean workspace" step from NetBSD regression job
Hi, I have removed "clean workspace" from NetBSD regression job too. Vijay had earlier removed it from CentOS regression. Cleaning the workspace resulted in deletion of complete git repo and re-clone takes a lot of time. Gerrit trigger/Git plugin intelligently reset to HEAD~n when moving to next job and hence save time. Thanks Raghavendra Talur ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] Enabling comment based trigger on jenkins
Hi, Prashanth informed about a simple way to let every contributor retrigger the regression runs that openstack uses. Contributor has to simply post "recheck no bug" as comment on the patch set. Read more here: http://zqfan.github.io/openstack/2014/01/03/what-should-i-do-when-jenkins-fails/ I tweaked it for gluster, enabled and tested it. Trigger comments are: recheck netbsd recheck smoke recheck centos If no one has any objections to this method(security implications included), then I would like to announce it on gluster-devel. Thanks, Raghavendra Talur ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] [Gluster-devel] Smoke tests run on the builder in RH DC (at least)
On Mon, Jan 25, 2016 at 11:29 PM, Michael Scherer wrote: > Hi, > > so today, after fixing one last config item, the smoke test jobs run > fine on the Centos 6 builder in the RH DC, which build things as non > root, then start the tests, then reboot the server. > Awesome! > > Now, I am looking at the fedora one, but once this one is good, I will > likely reinstall a few builders as a test, and go on Centos 7 builder. > This is what I had to do to get Fedora working. Ansible lines are shown where applicable. 1. change ownership for python site packages: difference is in version 2.7 when compared to 2.6 of CentOS file: path=/usr/lib/python2.7/site-packages/gluster/ state=directory owner=jenkins group=root 2. Had to give jenkins write permission on /usr/lib/systemd/system/ for installing glusterd service file. > I was also planning to look at jenkins job builder for the jenkins, but > no time yet. Will be after jenkins migration to a new host (which is > still not planned, unlike gerrit where we should be attempting to find a > time for that) > > > -- > Michael Scherer > Sysadmin, Community Infrastructure and Platform, OSAS > > > > ___ > Gluster-devel mailing list > gluster-de...@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Vagrant box upload: Was: [Change in glusterfs[master]: vagrant-test: Use pre-baked box for better perf]
On Fri, Jan 22, 2016 at 10:09 PM, Raghavendra Talur wrote: > > > On Fri, Jan 22, 2016 at 9:03 PM, Niels de Vos wrote: > >> On Fri, Jan 22, 2016 at 08:17:17PM +0530, Raghavendra Talur wrote: >> > On Tue, Jan 19, 2016 at 2:54 PM, Niels de Vos >> wrote: >> > >> > > On Mon, Jan 18, 2016 at 10:23:00PM +0530, Raghavendra Talur wrote: >> > > > Michael has a good point that we should host this(or updated and >> better) >> > > > vagrant box for Gluster development under Gluster entity. It could >> be a >> > > > Gluster account in https://atlas.hashicorp.com or could be hosted >> > > somewhere >> > > > on gluster.org. >> > > > >> > > > Thoughts? >> > > >> > > Maybe start with placing it on download.gluster.org? >> > > >> > >> > I have created the catalog file and uploaded the box at atlas. >> > >> > To get it on download.gluster.org, here is what we should do: >> > >> > 1. mkdir -p pub/gluster/glusterfs/vagrant/gluster-dev-fedora/boxes/ >> > 2. download gluster-dev-fedora.json that is attached >> > 3. mv >> > gluster-dev-fedora.json pub/gluster/glusterfs/vagrant/gluster-dev-fedora >> > 4. wget >> > >> https://atlas.hashicorp.com/raghavendra-talur/boxes/gluster-dev-fedora/versions/0.3/providers/libvirt.box >> > 5. verify sha1sum libvirt.box is >> bd0724d2e346832fd159f05e96aefbc88c4b222a >> > 6. mv >> > libvirt.box >> pub/gluster/glusterfs/vagrant/gluster-dev-fedora/boxes/gluster-dev-fedora_0.3.box >> >> It is not clear what Fedora version this is. Should that not be part of >> the name, or at least description in the .json? Because it is Fedora, it >> will need relatively frequent updates, how are you planning to get those >> published? Would it not be easier to use CentOS for this? After all, we >> use CentOS on our Jenkins slaves too. >> > > The version of fedora is omitted because I intend to upgrade the fedora > version in the box. Fedora releases too often to make different box > versions for each of them. For example this is 0.3 version. When I rebase > to F24, it will be 0.4. The description is again for the main box and not > the version number. > > I was not able to use CentOS because it does not have a trusted box > published for CentOS 6[1]. I choose to use the trusted Fedora vagrant box > [2] instead of CentOS 7 as most developers have Fedora as their dev machine. > I have a patch in progress for vagrant-test where one could specify a > different base box, so it should not be a problem if someone wants a CentOS > 7 box. > > > [1] https://wiki.centos.org/Download > [2] https://atlas.hashicorp.com/fedora/boxes/23-cloud-base > > Bump. Let me know if you have any other suggestions. I want to do a demo video of this sometime this week once the box is uploaded. > >> > I request Michael to upload the box, once done, I will update the patch. >> > >> > >> > >> > >> > > It would surely need some documentation on gluster.readthedocs.org >> too? >> > > >> > >> > I am working on the patch. It has info given in this[ >> > http://review.gluster.org/#/c/12753/] patch with more detail. >> >> Ok, thanks! >> Niels >> >> >> > >> > >> > >> > > Thanks, >> > > Niels >> > > >> > > > >> > > > -- Forwarded message -- >> > > > From: Michael Adam (Code Review) >> > > > Date: Mon, Jan 18, 2016 at 4:15 PM >> > > > Subject: Change in glusterfs[master]: vagrant-test: Use pre-baked >> box for >> > > > better perf >> > > > To: Raghavendra Talur >> > > > Cc: Gluster Build System , Kaushal M < >> > > > kaus...@redhat.com>, Niels de Vos , Michael >> Adam < >> > > > ob...@samba.org> >> > > > >> > > > >> > > > Michael Adam has posted comments on this change. >> > > > >> > > > Change subject: vagrant-test: Use pre-baked box for better perf >> > > > >> .. >> > > > >> > > > >> > > > Patch Set 1: >> > > > >> > > > (2 comments) >> > > > >> > > > some comments inline >> > > > >> > > > >> > > >> http://review.gluster.org/#/c/13251/1/tests/vagrant/vagrant-template/Vagrantfile >> > > > File tests/vagrant/vagrant-template/Vagrantfile: >> > > > >> > > > Ideally, at some point, there should be a gluster entity under >> atlast. >> > > > Alternatively we could directly specify a download url for the box >> onder >> > > > gluster.org >> > > >> > > > ___ >> > > > Gluster-infra mailing list >> > > > Gluster-infra@gluster.org >> > > > http://www.gluster.org/mailman/listinfo/gluster-infra >> > > >> > > >> >> >> > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Vagrant box upload: Was: [Change in glusterfs[master]: vagrant-test: Use pre-baked box for better perf]
On Fri, Jan 22, 2016 at 9:03 PM, Niels de Vos wrote: > On Fri, Jan 22, 2016 at 08:17:17PM +0530, Raghavendra Talur wrote: > > On Tue, Jan 19, 2016 at 2:54 PM, Niels de Vos wrote: > > > > > On Mon, Jan 18, 2016 at 10:23:00PM +0530, Raghavendra Talur wrote: > > > > Michael has a good point that we should host this(or updated and > better) > > > > vagrant box for Gluster development under Gluster entity. It could > be a > > > > Gluster account in https://atlas.hashicorp.com or could be hosted > > > somewhere > > > > on gluster.org. > > > > > > > > Thoughts? > > > > > > Maybe start with placing it on download.gluster.org? > > > > > > > I have created the catalog file and uploaded the box at atlas. > > > > To get it on download.gluster.org, here is what we should do: > > > > 1. mkdir -p pub/gluster/glusterfs/vagrant/gluster-dev-fedora/boxes/ > > 2. download gluster-dev-fedora.json that is attached > > 3. mv > > gluster-dev-fedora.json pub/gluster/glusterfs/vagrant/gluster-dev-fedora > > 4. wget > > > https://atlas.hashicorp.com/raghavendra-talur/boxes/gluster-dev-fedora/versions/0.3/providers/libvirt.box > > 5. verify sha1sum libvirt.box is bd0724d2e346832fd159f05e96aefbc88c4b222a > > 6. mv > > libvirt.box > pub/gluster/glusterfs/vagrant/gluster-dev-fedora/boxes/gluster-dev-fedora_0.3.box > > It is not clear what Fedora version this is. Should that not be part of > the name, or at least description in the .json? Because it is Fedora, it > will need relatively frequent updates, how are you planning to get those > published? Would it not be easier to use CentOS for this? After all, we > use CentOS on our Jenkins slaves too. > The version of fedora is omitted because I intend to upgrade the fedora version in the box. Fedora releases too often to make different box versions for each of them. For example this is 0.3 version. When I rebase to F24, it will be 0.4. The description is again for the main box and not the version number. I was not able to use CentOS because it does not have a trusted box published for CentOS 6[1]. I choose to use the trusted Fedora vagrant box [2] instead of CentOS 7 as most developers have Fedora as their dev machine. I have a patch in progress for vagrant-test where one could specify a different base box, so it should not be a problem if someone wants a CentOS 7 box. [1] https://wiki.centos.org/Download [2] https://atlas.hashicorp.com/fedora/boxes/23-cloud-base > > I request Michael to upload the box, once done, I will update the patch. > > > > > > > > > > > It would surely need some documentation on gluster.readthedocs.org > too? > > > > > > > I am working on the patch. It has info given in this[ > > http://review.gluster.org/#/c/12753/] patch with more detail. > > Ok, thanks! > Niels > > > > > > > > > > > Thanks, > > > Niels > > > > > > > > > > > -- Forwarded message -- > > > > From: Michael Adam (Code Review) > > > > Date: Mon, Jan 18, 2016 at 4:15 PM > > > > Subject: Change in glusterfs[master]: vagrant-test: Use pre-baked > box for > > > > better perf > > > > To: Raghavendra Talur > > > > Cc: Gluster Build System , Kaushal M < > > > > kaus...@redhat.com>, Niels de Vos , Michael Adam > < > > > > ob...@samba.org> > > > > > > > > > > > > Michael Adam has posted comments on this change. > > > > > > > > Change subject: vagrant-test: Use pre-baked box for better perf > > > > > .. > > > > > > > > > > > > Patch Set 1: > > > > > > > > (2 comments) > > > > > > > > some comments inline > > > > > > > > > > > > http://review.gluster.org/#/c/13251/1/tests/vagrant/vagrant-template/Vagrantfile > > > > File tests/vagrant/vagrant-template/Vagrantfile: > > > > > > > > Ideally, at some point, there should be a gluster entity under > atlast. > > > > Alternatively we could directly specify a download url for the box > onder > > > > gluster.org > > > > > > > ___ > > > > Gluster-infra mailing list > > > > Gluster-infra@gluster.org > > > > http://www.gluster.org/mailman/listinfo/gluster-infra > > > > > > > > > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Vagrant box upload: Was: [Change in glusterfs[master]: vagrant-test: Use pre-baked box for better perf]
On Tue, Jan 19, 2016 at 2:54 PM, Niels de Vos wrote: > On Mon, Jan 18, 2016 at 10:23:00PM +0530, Raghavendra Talur wrote: > > Michael has a good point that we should host this(or updated and better) > > vagrant box for Gluster development under Gluster entity. It could be a > > Gluster account in https://atlas.hashicorp.com or could be hosted > somewhere > > on gluster.org. > > > > Thoughts? > > Maybe start with placing it on download.gluster.org? > I have created the catalog file and uploaded the box at atlas. To get it on download.gluster.org, here is what we should do: 1. mkdir -p pub/gluster/glusterfs/vagrant/gluster-dev-fedora/boxes/ 2. download gluster-dev-fedora.json that is attached 3. mv gluster-dev-fedora.json pub/gluster/glusterfs/vagrant/gluster-dev-fedora 4. wget https://atlas.hashicorp.com/raghavendra-talur/boxes/gluster-dev-fedora/versions/0.3/providers/libvirt.box 5. verify sha1sum libvirt.box is bd0724d2e346832fd159f05e96aefbc88c4b222a 6. mv libvirt.box pub/gluster/glusterfs/vagrant/gluster-dev-fedora/boxes/gluster-dev-fedora_0.3.box I request Michael to upload the box, once done, I will update the patch. > It would surely need some documentation on gluster.readthedocs.org too? > I am working on the patch. It has info given in this[ http://review.gluster.org/#/c/12753/] patch with more detail. > Thanks, > Niels > > > > > -- Forwarded message -- > > From: Michael Adam (Code Review) > > Date: Mon, Jan 18, 2016 at 4:15 PM > > Subject: Change in glusterfs[master]: vagrant-test: Use pre-baked box for > > better perf > > To: Raghavendra Talur > > Cc: Gluster Build System , Kaushal M < > > kaus...@redhat.com>, Niels de Vos , Michael Adam < > > ob...@samba.org> > > > > > > Michael Adam has posted comments on this change. > > > > Change subject: vagrant-test: Use pre-baked box for better perf > > .. > > > > > > Patch Set 1: > > > > (2 comments) > > > > some comments inline > > > > > http://review.gluster.org/#/c/13251/1/tests/vagrant/vagrant-template/Vagrantfile > > File tests/vagrant/vagrant-template/Vagrantfile: > > > > Ideally, at some point, there should be a gluster entity under atlast. > > Alternatively we could directly specify a download url for the box onder > > gluster.org > > > ___ > > Gluster-infra mailing list > > Gluster-infra@gluster.org > > http://www.gluster.org/mailman/listinfo/gluster-infra > > gluster-dev-fedora.json Description: application/json ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] [Gluster-devel] Jenkins accounts for all devs.
On Fri, Jan 22, 2016 at 2:41 PM, Michael Scherer wrote: > Le vendredi 22 janvier 2016 à 11:31 +0530, Ravishankar N a écrit : > > On 01/14/2016 12:16 PM, Kaushal M wrote: > > > On Thu, Jan 14, 2016 at 10:33 AM, Raghavendra Talur > wrote: > > >> > > >> On Thu, Jan 14, 2016 at 10:32 AM, Ravishankar N < > ravishan...@redhat.com> > > >> wrote: > > >>> On 01/08/2016 12:03 PM, Raghavendra Talur wrote: > > >>>> P.S: Stop using the "universal" jenkins account to trigger jenkins > build > > >>>> if you are not a maintainer. > > >>>> If you are a maintainer and don't have your own jenkins account > then get > > >>>> one soon! > > >>>> > > >>> I would request for a jenkins account for non-maintainers too, at > least > > >>> for the devs who are actively contributing code (as opposed to random > > >>> one-off commits from persons). That way, if the regression failure is > > >>> *definitely* not in my patch (or) is a spurious failure (or) is > something > > >>> that I need to take a netbsd slave offline to debug etc., I don't > have to > > >>> be blocked on the Maintainer. Since the accounts are anyway tied to > an > > >>> individual, it should be easy to spot if someone habitually > re-trigger > > >>> regressions without any initial debugging. > > >>> > > >> +1 > > > We'd like to give everyone accounts. But the way we're providing > > > accounts now gives admin accounts to all. This is not very secure. > > > > > > This was one of the reasons misc setup freeipa.gluster.org, to provide > > > controlled accounts for all. But it hasn't been used yet. We would > > > need to integrate jenkins and the slaves with freeipa, which would > > > give everyone easy access. > > > > Hi Michael, > > Do you think it is possible to have this integration soon so that all > > contributors can re-trigger/initiate builds by themselves? > > The thing that is missing is still the same, how do we consider that > someone is a contributor. IE, do we want people just say "add me" and > get root access to all our jenkins builder (because that's also what go > with jenkins way of restarting a build for now) ? > > I did the technical stuff, but so far, no one did the organisational > part of giving a criteria for who has access to what. Without clear > process, I can't do much. > +ndevos +vijay Something like "should have contributed 10 patches to Gluster and be supported by at least 1 maintainer" would do? -- > Michael Scherer > Sysadmin, Community Infrastructure and Platform, OSAS > > > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Linux regression tests are hanging too
On Tue, Jan 19, 2016 at 5:20 PM, Pranith Kumar Karampuri < pkara...@redhat.com> wrote: > Result: PASS > Build timed out (after 300 minutes). Marking the build as failed. > Build was aborted > Finished: FAILURE > > > https://build.gluster.org/job/rackspace-regression-2GB-triggered/17664/console > > Pranith > This is due to build timeout. I had set it to 300 minute (5 hours). Recently though, some patch has caused a major performance regression. Tests which used to pass in 120 seconds are taking more than 200. This has increased test run time from 200 minutes to greater than 300. I have increased timeout value to 500 minutes now and it should not get aborted. Someone really needs to look into the regression though. Pick any test from the console output above and run a .t file that took over 20 ms. Thanks, Raghavendra ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Trouble adding a new Gerrit configuration to Jenkins for Smoke tests
On Sat, Jan 16, 2016 at 5:16 PM, Niels de Vos wrote: > Hi, > > I'm trying to add a copy of the existing Gerrit server to Jenkins, but > seem to be unable to get it connected. I've started with [add server] > and [copy from existing server] to create > "review.gluster.org_for-smoke-jobs". The [Advanced] "Gerrit Verified > Commands" have been modified to set the Smoke label instead of the > default Verified. > > Clicking the [test connection] button return success (after removing the > ***-out password). But after saving and clicking the red [o] button to > connect the server, it just seems to time-out. > > Some assistence with getting this server connected is most welcome. > Please see these links for checking: > > https://build.gluster.org/gerrit-trigger/ > > https://build.gluster.org/gerrit-trigger/server/review.gluster.org_for-smoke-jobs/ > > I tried but could not figure out the reason either. Is this still required? > Thanks, > Niels > > ___ > Gluster-infra mailing list > Gluster-infra@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-infra > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] Vagrant box upload: Was: [Change in glusterfs[master]: vagrant-test: Use pre-baked box for better perf]
Michael has a good point that we should host this(or updated and better) vagrant box for Gluster development under Gluster entity. It could be a Gluster account in https://atlas.hashicorp.com or could be hosted somewhere on gluster.org. Thoughts? -- Forwarded message -- From: Michael Adam (Code Review) Date: Mon, Jan 18, 2016 at 4:15 PM Subject: Change in glusterfs[master]: vagrant-test: Use pre-baked box for better perf To: Raghavendra Talur Cc: Gluster Build System , Kaushal M < kaus...@redhat.com>, Niels de Vos , Michael Adam < ob...@samba.org> Michael Adam has posted comments on this change. Change subject: vagrant-test: Use pre-baked box for better perf .. Patch Set 1: (2 comments) some comments inline http://review.gluster.org/#/c/13251/1/tests/vagrant/vagrant-template/Vagrantfile File tests/vagrant/vagrant-template/Vagrantfile: Ideally, at some point, there should be a gluster entity under atlast. Alternatively we could directly specify a download url for the box onder gluster.org ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Requesting separate labels in Gerrit for better testing results
On Fri, Jan 15, 2016 at 4:22 PM, Niels de Vos wrote: > On Thu, Jan 14, 2016 at 10:26:46PM +0530, Kaushal M wrote: > > I'd pushed the config to a new branch instead of updating the > > `refs/meta/config` branch. I've corrected this now. > > > > The 3 new labels are, > > - Smoke > > - CentOS-regression > > - NetBSD-regression > > > > The new labels are active now. Changes cannot be merged without all of > > them being +1. Only the bot accounts (Gluster Build System and NetBSD > > Build System) can set them. > Thanks Kaushal ! > > It seems that Verified is also a label that is required. Because this is > now the label for manual testing by reviewers/qa, I do not think it > should be a requirement anymore. > > Could the labels that are needed for merging be setup like this? > > Code-Review=+2 && (Verified=+1 || (Smoke=+1 && CentOS-regression=+1 && > NetBSD-regression=+1)) > I would prefer not having Verified=+1 here. A dev should not be allowed to override the restrictions. > > I managed to get http://review.gluster.org/13208 merged now, please > check if the added tags in the commit message are ok, or need to get > modified. > > Thanks, > Niels > > > > > > On Thu, Jan 14, 2016 at 9:22 PM, Kaushal M wrote: > > > On Thu, Jan 14, 2016 at 5:12 PM, Niels de Vos > wrote: > > >> On Thu, Jan 14, 2016 at 03:46:02PM +0530, Kaushal M wrote: > > >>> On Thu, Jan 14, 2016 at 2:43 PM, Niels de Vos > wrote: > > >>> > On Thu, Jan 14, 2016 at 11:51:15AM +0530, Raghavendra Talur wrote: > > >>> >> On Tue, Jan 12, 2016 at 7:59 PM, Atin Mukherjee < > atin.mukherje...@gmail.com> > > >>> >> wrote: > > >>> >> > > >>> >> > -Atin > > >>> >> > Sent from one plus one > > >>> >> > On Jan 12, 2016 7:41 PM, "Niels de Vos" > wrote: > > >>> >> > > > > >>> >> > > On Tue, Jan 12, 2016 at 07:21:37PM +0530, Raghavendra Talur > wrote: > > >>> >> > > > We have now changed the gerrit-jenkins workflow as follows: > > >>> >> > > > > > >>> >> > > > 1. Developer works on a new feature/bug fix and tests it > locally(run > > >>> >> > > > run-tests.sh completely). > > >>> >> > > > 2. Developer sends the patch to gerrit using rfc.sh. > > >>> >> > > > > > >>> >> > > > +++Note that no regression runs have started automatically > for this > > >>> >> > patch > > >>> >> > > > at this point.+++ > > >>> >> > > > > > >>> >> > > > 3. Developer marks the patch as +1 verified on gerrit as a > promise of > > >>> >> > > > having tested the patch completely. For cases where patches > don't have > > >>> >> > a +1 > > >>> >> > > > verified from the developer, maintainer has the following > options > > >>> >> > > > a. just do the code-review and award a +2 code review. > > >>> >> > > > b. pull the patch locally and test completely and award a > +1 verified. > > >>> >> > > > Both the above actions would result in triggering of > regression runs > > >>> >> > for > > >>> >> > > > the patch. > > >>> >> > > > > >>> >> > > Would it not help if anyone giving +1 code-review starts the > regression > > >>> >> > > tests too? When developers ask me to review, I prefer to see > reviews > > >>> >> > > done by others first, and any regression failures should have > been fixed > > >>> >> > > by the time I look at the change. > > >>> >> > When this idea was originated (long back) I was in favour of > having > > >>> >> > regression triggered on a +1, however verified flag set by the > developer > > >>> >> > would still trigger the regression. Being a maintainer I would > always > > >>> >> > prefer to look at a patch when its verified flag is +1 which > means the > > >>> >> > regression result would also be available. > > >>> >> > > > >>> >> > >
Re: [Gluster-infra] Requesting separate labels in Gerrit for better testing results
On Thu, Jan 14, 2016 at 2:43 PM, Niels de Vos wrote: > On Thu, Jan 14, 2016 at 11:51:15AM +0530, Raghavendra Talur wrote: > > On Tue, Jan 12, 2016 at 7:59 PM, Atin Mukherjee < > atin.mukherje...@gmail.com> > > wrote: > > > > > -Atin > > > Sent from one plus one > > > On Jan 12, 2016 7:41 PM, "Niels de Vos" wrote: > > > > > > > > On Tue, Jan 12, 2016 at 07:21:37PM +0530, Raghavendra Talur wrote: > > > > > We have now changed the gerrit-jenkins workflow as follows: > > > > > > > > > > 1. Developer works on a new feature/bug fix and tests it > locally(run > > > > > run-tests.sh completely). > > > > > 2. Developer sends the patch to gerrit using rfc.sh. > > > > > > > > > > +++Note that no regression runs have started automatically for this > > > patch > > > > > at this point.+++ > > > > > > > > > > 3. Developer marks the patch as +1 verified on gerrit as a promise > of > > > > > having tested the patch completely. For cases where patches don't > have > > > a +1 > > > > > verified from the developer, maintainer has the following options > > > > > a. just do the code-review and award a +2 code review. > > > > > b. pull the patch locally and test completely and award a +1 > verified. > > > > > Both the above actions would result in triggering of regression > runs > > > for > > > > > the patch. > > > > > > > > Would it not help if anyone giving +1 code-review starts the > regression > > > > tests too? When developers ask me to review, I prefer to see reviews > > > > done by others first, and any regression failures should have been > fixed > > > > by the time I look at the change. > > > When this idea was originated (long back) I was in favour of having > > > regression triggered on a +1, however verified flag set by the > developer > > > would still trigger the regression. Being a maintainer I would always > > > prefer to look at a patch when its verified flag is +1 which means the > > > regression result would also be available. > > > > > > > > > Niels requested in IRC that it is good have a mechanism of getting all > > patches that have already passed all regressions before starting review. > > Here is what I found > > a. You can use the search string > > status:open label:Verified+1,user=build AND > label:Verified+1,user=nb7build > > b. You can bookmark this link and it will take you directly to the page > > with list of such patches. > > > > > http://review.gluster.org/#/q/status:open+label:Verified%252B1%252Cuser%253Dbuild+AND+label:Verified%252B1%252Cuser%253Dnb7build > > Hmm, copy/pasting this URL does not work for me, I get an error: > > Code Review - Error > line 1:26 no viable alternative at character '%' > [Continue] > Firefox bug, Works for me in chrome Here is the proof https://code.google.com/p/gerrit/issues/detail?id=3641 https://code.google.com/p/gerrit/issues/detail?id=3582 > > > Kaushal, could you add the following labels to gerrit, so that we can > update the Jenkins jobs and they can start setting their own labels? > > http://review.gluster.org/Documentation/config-labels.html#label_custom > > - Smoke: misc smoke testing, compile, bug check, posix, .. > - NetBSD: NetBSD-7 regression > - Linux: Linux regression on CentOS-6 > > Users/developers should not be able to set these labels, only the > Jenkins accounts are allowed to. > > The standard Verified label can then be used for manual verification by > developers, qa and reviewers. > > Thanks, > Niels > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Jenkins slave32 seems broken?
On Wed, Jan 13, 2016 at 3:49 PM, Niels de Vos wrote: > On Wed, Jan 13, 2016 at 10:35:42AM +0100, Xavier Hernandez wrote: > > The same has happened to slave34.cloud.gluster.org. I've disabled it to > > allow regressions to be run on other slaves. > > > > There are two files owned by root inside > > /home/jenkins/root/workspace/rackspace-regression-2GB-triggered: > > > > -rwxr-xr-x 1 rootroot 10124 Jan 7 17:54 file_lock > > drwxr-xr-x 3 rootroot 4096 Jan 7 18:31 > slave34.cloud.gluster.org: > > Thanks! > > I've looked into this a little more now, and might have identified the > problem. > > This one failed with an unrelated error: > > > https://build.gluster.org/job/rackspace-regression-2GB-triggered/17413/console > > ... > Building remotely on slave34.cloud.gluster.org > (rackspace_regression_2gb) in workspace > /home/jenkins/root/workspace/rackspace-regression-2GB-triggered >> git rev-parse --is-inside-work-tree # timeout=10 > Fetching changes from the remote Git repository >> git config remote.origin.url git://review.gluster.org/glusterfs.git > # timeout=10 > Fetching upstream changes from git://review.gluster.org/glusterfs.git > ... > > The next run on slave34 failed because of the weird directory: > > > https://build.gluster.org/job/rackspace-regression-2GB-triggered/17440/console > > ... > Building remotely on slave34.cloud.gluster.org > (rackspace_regression_2gb) in workspace > /home/jenkins/root/workspace/rackspace-regression-2GB-triggered > Wiping out workspace first. > java.io.IOException: remote file operation failed: > /home/jenkins/root/workspace/rackspace-regression-2GB-triggered at > hudson.remoting.Channel@62ecdacb:slave34.cloud.gluster.org: > ... > > Note the "Wiping out workspace first." line. This comes from an option > in the regression job. This seems to be a recently added "Additional > Behaviour" in the Jenkins job. Did anyone add this on purpose, or was > that automatically done with a Jenkins update or something? > The three additional behaviour added in regression configuration were added by me and I simply copied whatever was there in smoke configuration page. We can try removing this configuration line but the tests weren't getting started without this(we got it running after a restart so this might be false requirement). Technically, it is not a harmful configuration and wiki pages recommend it. It says such errors occur only if files were created and left open/locked by some tests or were created with different permissions. We still need to identify what tests are responsible for this. > > Niels > > > > > Xavi > > > > On 12/01/16 12:06, Niels de Vos wrote: > > >Hi, > > > > > >I've disabled slave32.cloud.gluster.org because it failed multiple > > >regression tests with a weird error. After disabling slave32 and > > >retriggering the failed run, the same job executed fine on a different > > >slave. > > > > > >The affected directory is owned by root, so the jenkins user is not > > >allowed to wipe it. Does anyone know how this could happen? The dirname > > >is rather awkward too... > > > > > > > > /home/jenkins/root/workspace/rackspace-regression-2GB-triggered/slave32.cloud.gluster.org: > /d > > > > > >I think we can just remove that dir and the slave can be enabled again. > > >Leaving the status as is for further investigation. > > > > > >Thanks, > > >Niels > > > > > > > > >Full error: > > > > > > Wiping out workspace first. > > > java.io.IOException: remote file operation failed: > /home/jenkins/root/workspace/rackspace-regression-2GB-triggered at > hudson.remoting.Channel@7bc1e07d:slave32.cloud.gluster.org: > java.nio.file.AccessDeniedException: > /home/jenkins/root/workspace/rackspace-regression-2GB-triggered/slave32.cloud.gluster.org: > /d > > > at hudson.FilePath.act(FilePath.java:986) > > > at hudson.FilePath.act(FilePath.java:968) > > > at hudson.FilePath.deleteContents(FilePath.java:1183) > > > at > hudson.plugins.git.extensions.impl.WipeWorkspace.beforeCheckout(WipeWorkspace.java:28) > > > at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1040) > > > at hudson.scm.SCM.checkout(SCM.java:485) > > > at > hudson.model.AbstractProject.checkout(AbstractProject.java:1276) > > > at > hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607) > > > at > jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) > > > at > hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529) > > > at hudson.model.Run.execute(Run.java:1738) > > > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) > > > at > hudson.model.ResourceController.execute(ResourceController.java:98) > > > at hudson.model.Executor.run(Executor.java:410) > > > Caused by: java.nio.file.AccessDeniedException: > /home/jenki
[Gluster-infra] Need help with gerrit trigger plugin
I am reconfiguring the events to trigger jenkins build on. The events are not getting triggered though. Checking the config page for trigger plugin I see this [image: Inline image 1] May be this is the reason for it, could someone check the ssh file and password? Thanks, Raghavendra Talur ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] Timeout for jenkins builds
On Thu, Jan 7, 2016 at 4:26 PM, Niels de Vos wrote: > On Thu, Jan 07, 2016 at 03:32:57PM +0530, Raghavendra Talur wrote: > > Hi, > > > > I have enabled timeouts for jenkins builds. > > Regression on CentOS and NetBSD now both have a 300 minutes(5 hour) > timeout > > and tests will be marked "FAILED" when if it does not complete by then. > > Do you know who is investigating these hangs? > This is already done. Thanks to Manikandan and Raghavendra Gowdappa for getting debug info and providing fix respectively. Here is the fix http://review.gluster.org/#/c/13177/ and it is already merged. Rebase your patches to get them pass on NetBSD. > > > This is keeping in view the recent hangs which ran tests for more than > > 10-14 hour. > > > > Also, the script used in NetBSD does not do any cleanup between runs like > > the CentOS script does. > > I did not modify it for now but we should. Let me know If someone wants > to > > take it up. I will have a go at it next week if there are no replies. > > It would be nice to have an extremely simple Jenkins job, that only > executes a script that is located on disk. Could we get such a script in > https://github.com/gluster/glusterfs-patch-acceptance-tests so that we > can easily start running regression tests in the CentOS CI as well? > +10 Some questions: 1. Currently our images have all the packages baked in, what would be the implication if the slaves are fresh CentOS images and need to download the packages as part of a ansible playbook? 2. Instead of regression.sh(in glusterfs-patch-acceptance-tests), run-tests.sh(in glusterfs) is the place where most of the intelligence should reside. This would make creating jenkins job much simpler. Thoughts? > > I would also like to have the Jenkins jobs exported as XML and saved in > the same git repository. That should make it much easier to import the > jobs in other Jenkins environments. Exporting and importing can be done > with the Jenkins CLI, see http://build.gluster.org/cli for details. > Awesome idea!!! > > Thanks, > Niels > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] nbslave71 needs to be re-imaged
Hi, I had disabled nbslave71 slave long back in Sep due to scripts being overwritten by log issues and had not followed it up. This needs to be re-imaged, I guess misc or manu can help me with that? Thanks, Raghavendra Talur ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] [Gluster-devel] Lot of Netbsd regressions 'Waiting for the next available executor'
You can log in. I think the HUP signal did not cause any change in process state. I still see it in I state. pid is 10967. On Thu, Dec 31, 2015 at 3:26 PM, Emmanuel Dreyfus wrote: > On Thu, Dec 31, 2015 at 03:22:54PM +0530, Raghavendra Talur wrote: > > Manu, this seems to be a bug in libperfuse and not in Gluster. > > The machine is nbslave75.cloud.gluster.org. You will have to rerun > > quota.t couple of times to hit the bug. The test would hang in line > 62(TEST > > 24). > > There is a jenkins job running on that machine. May I proceed? Where > is the relevant test suite? > > A nice way of handling over the bug to someone else could be to run in > the screen utility. > > -- > Emmanuel Dreyfus > m...@netbsd.org > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] [Gluster-devel] Lot of Netbsd regressions 'Waiting for the next available executor'
Hi, I got info from one of the slave machines, bt from perfused process #0 0xbb679a77 in _sys___kevent50 () from /usr/lib/libc.so.12 (gdb) info threads Id Target Id Frame * 1process 26515 0xbb679a77 in _sys___kevent50 () from /usr/lib/libc.so.12 bt from mount process (gdb) bt #0 0xbb3bb4b7 in ___lwp_park60 () from /usr/lib/libc.so.12 Manu, this seems to be a bug in libperfuse and not in Gluster. The machine is nbslave75.cloud.gluster.org. You will have to rerun quota.t couple of times to hit the bug. The test would hang in line 62(TEST 24). Thanks, Raghavendra Talur On Thu, Dec 24, 2015 at 3:32 PM, Emmanuel Dreyfus wrote: > On Thu, Dec 24, 2015 at 01:44:21AM -0500, Raghavendra Gowdappa wrote: > > > Seems to be hung. May be a hung syscall? I've tried to kill it, but > seems > > > like its not dead. May be patch #12594 is causing some issues on > netbsd. It > > > has passed gluster regression. > > ps -axl shows PID 1394 (umount) waiting on tstile, which is used for > spinlocks. No process should sit there for long, unless there is a > kernel locking problem (which may be a userland locking problem > thanks to FUSE). > > Using crash(8) I can see umount is awaiting for a vnode lock. There > is certainly something to investigate but I lack time for now. I > issued a reboot. Please tell me if you can reproduce it. > > -- > Emmanuel Dreyfus > m...@netbsd.org > ___ > Gluster-devel mailing list > gluster-de...@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] slave21 and 23 offline due to disk full
On Wed, Sep 9, 2015 at 8:21 PM, Michael Scherer wrote: > Hi, > > just found out that slave21 and 23 were offline due to their disk being > full. The issue is 14G of log, due to something creating tarball > of /var/log/glusterfs, and place the tarball in /var/log/glusterfs/ > > Ndevos say the bug is fixed, but I would rather investigate in more > details, someone has some information, pointer ? > > (slave26 and slave46 are however just without ssh, so going to reboot > them) > I am the culprit. This patch http://review.gluster.org/#/c/12109/ is the reason and it has been taken care of. The test ran on sept 5th. If the slave had a little space left and executed next build then the logs must have got cleared and it should be fine. Sorry for the trouble, will be more careful next time I am messing with test infra scripts. A better fix is posted at http://review.gluster.org/#/c/12110/ and waiting for reviews! -- > Michael Scherer > Sysadmin, Community Infrastructure and Platform, OSAS > > > ___ > Gluster-infra mailing list > Gluster-infra@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-infra > > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] No linux slaves up in jenkins
On Sat, Sep 5, 2015 at 1:40 PM, Niels de Vos wrote: > On Sat, Sep 05, 2015 at 01:11:49PM +0530, Raghavendra Talur wrote: > > I started the 10 iteration test today by this patch set > > http://review.gluster.org/#/c/12109/ > > > > However, it seems no slaves are online for linux. If someone gets to know > > why please update here. > > The Linux slaves always disconnect their Jenkins client and get marked > offline. When tests get started, the Jenkins master connects (ssh) to > the slaves and starts the Jenkins client. > > Is this not happening? You can manually force connecting by clicking on > the hostname of the slave, and then the [Launch slave agent] button. > I did not know about this. Yes, the slaves did come up after certain time. Thanks! > HTH, > Niels > ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
[Gluster-infra] No linux slaves up in jenkins
I started the 10 iteration test today by this patch set http://review.gluster.org/#/c/12109/ However, it seems no slaves are online for linux. If someone gets to know why please update here. Thanks Raghavendra Talur ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
Re: [Gluster-infra] bluild.gluster.org self signed cert
On Sat, Jul 18, 2015 at 9:14 PM, Emmanuel Dreyfus wrote: > Hi > > build.gluster.org presented me a self-signed certificate. I accepted it, > but please someone confirm it is on purpose. > > While there, startssl offers free certs... > Yes, that is intentional. Check thread with "jenkins over https" as subject. Latest update from misc is "So I did ask for a new cert, waiting on digicert." > > -- > Emmanuel Dreyfus > http://hcpnet.free.fr/pubz > m...@netbsd.org > ___ > Gluster-infra mailing list > Gluster-infra@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-infra > -- *Raghavendra Talur * ___ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra
