Perl 6 - the future is here, just unevenly distributed

IRC log for #gluster-dev, 2015-04-24

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:57 badone__ joined #gluster-dev
00:59 badone_ joined #gluster-dev
02:10 kbyrne joined #gluster-dev
02:30 wushudoin joined #gluster-dev
02:40 wushudoin left #gluster-dev
02:53 gem joined #gluster-dev
03:06 raghug joined #gluster-dev
03:24 gem joined #gluster-dev
03:27 wushudoin joined #gluster-dev
04:00 atinmu joined #gluster-dev
04:06 kdhananjay joined #gluster-dev
04:06 ppai joined #gluster-dev
04:08 ashishpandey joined #gluster-dev
04:14 ashishpandey joined #gluster-dev
04:20 kanagaraj joined #gluster-dev
04:27 overclk joined #gluster-dev
04:27 itisravi joined #gluster-dev
04:29 rjoseph joined #gluster-dev
04:30 sakshi joined #gluster-dev
04:36 shubhendu joined #gluster-dev
04:36 soumya joined #gluster-dev
04:41 anoopcs joined #gluster-dev
04:45 nbalacha joined #gluster-dev
04:46 kotreshhr joined #gluster-dev
04:49 hagarth joined #gluster-dev
04:52 jiffin joined #gluster-dev
04:56 nbalacha joined #gluster-dev
05:01 kshlm joined #gluster-dev
05:03 spandit joined #gluster-dev
05:03 lalatenduM joined #gluster-dev
05:15 gem joined #gluster-dev
05:16 ndarshan joined #gluster-dev
05:17 deepakcs joined #gluster-dev
05:29 kshlm I just killed and retriggered some hung regression jobs, that were ongoing for >10 hours.
05:35 gem_ joined #gluster-dev
05:39 ashiq joined #gluster-dev
05:45 soumya joined #gluster-dev
05:46 raghu joined #gluster-dev
05:47 hagarth kshlm: cool, thanks. can you also add a note to gerrit if not done so for those patches?
05:49 kshlm I don't remember which ones I retriggered, but I'll try.
05:50 gem_ joined #gluster-dev
05:54 Manikandan joined #gluster-dev
05:55 Manikandan_ joined #gluster-dev
05:57 kshlm I think I got all of them.
05:58 nkhare joined #gluster-dev
06:01 hagarth kshlm: great, thanks. I wonder if there's something else that is causing a hang.
06:02 kshlm Most likely some issue with the regression slaves :/
06:07 hagarth kshlm: I hope that's the case and nothing to do with our code!
06:17 kshlm Most of the jobs had hung without running even 1 test.
06:20 gem__ joined #gluster-dev
06:23 anoopcs Do we have a BZ for tracking coverity issues in release-3.7?
06:24 nishanth joined #gluster-dev
06:45 hagarth anoopcs: no, please go ahead and log one
06:50 gem__ joined #gluster-dev
06:59 hagarth kshlm: you are right, the slaves seem to have got into a problematic state
06:59 hagarth I see more tests and rpmbuilds hung now :-/
07:00 anoopcs hagarth: Ok.
07:01 aravindavk joined #gluster-dev
07:03 nbalacha joined #gluster-dev
07:03 Manikandan_ joined #gluster-dev
07:03 Manikandan joined #gluster-dev
07:14 nbalacha raghug, ping
07:14 glusterbot nbalacha: Please don't naked ping. http://blogs.gnome.org/mark​mc/2014/02/20/naked-pings/
07:14 nbalacha raghug, ping regarding gerrit access
07:28 anoopcs hchiramm++
07:28 glusterbot anoopcs: hchiramm's karma is now 28
07:35 gem__ joined #gluster-dev
07:49 raghug nbalacha: pong
07:49 raghug nbalacha: I've not got the access still
07:49 raghug I've reviewed susant's patch
07:49 raghug I've no concerns with the patch
07:50 raghug +1 from my end
07:58 raghug joined #gluster-dev
08:00 nbalacha joined #gluster-dev
08:00 ashishpandey joined #gluster-dev
08:01 hgowtham joined #gluster-dev
08:10 hchiramm raghug, ping
08:10 glusterbot hchiramm: Please don't naked ping. http://blogs.gnome.org/mark​mc/2014/02/20/naked-pings/
08:10 hchiramm 3.6.3 rpms are avilable @ download.gluster.org/pub/gl​uster/glusterfs/3.6/LATEST/
08:11 badone__ joined #gluster-dev
08:26 nbalacha joined #gluster-dev
08:45 ndarshan joined #gluster-dev
08:48 vikumar joined #gluster-dev
08:50 ira_ joined #gluster-dev
08:58 kdhananjay joined #gluster-dev
09:10 jiffin joined #gluster-dev
09:13 ndarshan joined #gluster-dev
09:21 ira joined #gluster-dev
09:22 raghug joined #gluster-dev
09:22 raghug JustinClift: are you there?
09:45 ashiq joined #gluster-dev
09:50 kshlm Lots of glusterfs-devrpms-el6 stuck at the same place.
09:50 kshlm All of them are stuck at the beginning of mock.
09:51 ndevos kshlm: hmm
09:51 kshlm Could be some issue with the centos vms?
09:52 itisravi_ joined #gluster-dev
09:53 ndevos kshlm: I'll check slave29 now, done kill the job there please :)
09:54 kshlm Okay.
09:54 kshlm It's okay if I kill the jobs on the others, right?
09:54 ndevos sure
09:55 ndevos hmm, there are actually other tests running on slave29 too..
09:56 ndevos the mock run once, and ./tests/basic/afr/data-self-heal.t is there 2x
09:57 ndevos kshlm: I think there is something not cleaning up very well, there is a stale /mnt/nfs/0 mountpoint too
09:57 ndevos well, 'stale' in the sense that its non-functional, but data-self-heal.t tries to use it
09:57 kshlm Oh! These vms could be the ones I aborted jobs on earlier.
09:58 kshlm AFAIK cleanup isn't done on aborting jobs.
09:59 ppai joined #gluster-dev
09:59 kshlm If a regression job runs next on the VM, probably it does the cleanup in the tests,
09:59 kshlm The rpmbuild job probably doesn't do any cleanup before starting.
10:01 hgowtham joined #gluster-dev
10:16 ndevos kshlm: yes, that looks like it, the mock process is hanging on some nfs things, and that can only happen when there is a broken nfs-mount in place
10:17 kshlm Thought as much.
10:18 ndevos kshlm: in fact, a crashing gluster/nfs process can result in those stale mount points... rebooting the vms is the easiest to solve those issues
10:18 kshlm It'll be nice to have refresh-slave-vm job, that would cleanup the whole vm.
10:18 * ndevos rebooted slave29 now
10:18 kshlm The reboot job would help as well.
10:19 ndevos it is not trivial to cleanup mounts of an nfs-server that went away...
10:19 ndevos like this mock process is accessing the nfs-mount, and it is blocked until the server comes back (which is, never)
10:22 kshlm Yeah. I've had this happen on my laptop several times when testing.
10:23 kshlm I've had to hard reboot. Thankfullly, I've not faced any data loss/corruption.
10:24 sakshi joined #gluster-dev
10:35 sakshi joined #gluster-dev
10:48 nbalacha joined #gluster-dev
11:02 nkhare_ joined #gluster-dev
11:02 raghug joined #gluster-dev
11:34 nbalacha JustinClift, please ping me when you come online
11:40 firemanxbr joined #gluster-dev
11:47 hagarth joined #gluster-dev
11:50 ashiq joined #gluster-dev
11:58 gem joined #gluster-dev
11:58 anoopcs joined #gluster-dev
11:59 rafi1 joined #gluster-dev
12:01 kanagaraj joined #gluster-dev
12:01 ashish__ joined #gluster-dev
12:01 anrao joined #gluster-dev
12:14 nishanth joined #gluster-dev
12:15 rjoseph joined #gluster-dev
12:15 gem joined #gluster-dev
12:17 ashiq joined #gluster-dev
12:23 shaunm_ joined #gluster-dev
12:29 rafi joined #gluster-dev
12:31 shyam joined #gluster-dev
12:32 mark_m_ joined #gluster-dev
12:32 mark_m_ Hi folks - can we get some help here - we are trying to use http://download.gluster.org/pub/gluster/g​lusterfs/LATEST/EPEL.repo/epel-6/x86_64/ to install the latest version, but when we do a "yum install glusterfs-fuse" the repo tells us 3.6.2 is available, BUT the repo only contains the new 3.6.3 files. Please advise?
12:34 JustinClift mark_m_: Hmmm, that's not good
12:34 mark_m_ :-(
12:34 JustinClift kkeithley: ^^^
12:35 JustinClift mark_m_: Just so I'm not misunderstanding.. you're wanting to install the very latest yeah? (which is 3.6.3)
12:35 hagarth joined #gluster-dev
12:35 mark_m_ Yes, latest is best, to keep up to date. But any 3.6.x version would be fine
12:37 JustinClift mark_m_: Which repo is yum saying that v3.6.2 of glusterfs-fuse is coming from?
12:37 kkeithley in a meeting, I'll take a look in a few minutes
12:37 JustinClift kkeithley: Cool
12:37 JustinClift mark_m_: I'm suspecting a repo conflict or something here (not 100% certain tho)
12:38 JustinClift mark_m_: Btw, 3.6.3 is definitely a better choice than earlier 3.6.x releases.  Important bug fixes. ;)
12:39 mark_m_ cheers
12:39 mark_m_ our file "/etc/yum.repos.d/glusterfs-epel.repo" has three entries
12:40 kkeithley Since 3.6.3 is out, if you're really determined to use 3.6.2, then fix your /etc/yum.repos.d/gluster.repo to point at http://download.gluster.org/pub/glu​ster/glusterfs/3.6/3.6.2/EPEL.repo/...
12:40 mark_m_ [glusterfs-epel] baseurl=http://download.gluster.org/pub/gluster/gluster​fs/LATEST/EPEL.repo/epel-$releasever/$basearch/ [glusterfs-noarch-epel] baseurl=http://download.gluster.org/pub/gluster/glust​erfs/LATEST/EPEL.repo/epel-$releasever/noarch [glusterfs-source-epel] baseurl=http://download.gluster.org/pub/gluster/glust​erfs/LATEST/EPEL.repo/epel-$releasever/SRPMS
12:40 dlambrig_ left #gluster-dev
12:40 JustinClift k, it looks like it *should* be grabbing the latest version
12:41 JustinClift Hang on, I'll spin up a CentOS 6.x VM and try it
12:41 kkeithley s/LATEST/3.6\/3.6.2/
12:41 mark_m_ we'd rather use "latest"
12:42 mark_m_ Yum reports errors like this: http://download.gluster.org/pub/gluste​r/glusterfs/LATEST/EPEL.repo/epel-6/x8​6_64/glusterfs-3.6.2-1.el6.x86_64.rpm: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found"
12:42 JustinClift Ahhh
12:42 JustinClift Ok, this might be a dumb question on my part
12:42 JustinClift Have you cleared the yum metadata cache?
12:42 mark_m_ ...because those uri's only have 3.6.3 in them. We did a "yum clean all"
12:42 JustinClift 3.6.3 is a brand new release (like right now-ish)
12:43 JustinClift So, if the metadata is updated once every 24 hours or something, it might just be stale metadata
12:44 kkeithley I've recreated the repo metadata. It's possible our person doing those has a bug in his process. do a clean and try again please
12:44 mark_m_ ...is there any chance the gluster server meta data is out of date? Very dumb question: have the gluster devs done a "createrepo --update" ???
12:44 mark_m_ trying now...
12:46 mark_m_ Same error here - which metatdata did you regenerate?
12:46 JustinClift k, I have a suitable CentOS 6.x VM starting up.  It's a bit out of date though, so it's yum updating first.
12:46 JustinClift Gimme 2-3 mins to make it decent, then I'll try to replicate the problem
12:46 kkeithley 3.6/3.6.3  a.k.a LATEST
12:47 soumya joined #gluster-dev
12:47 JustinClift mark_m_: If you do "yum install glusterfs-fuse", which repo does it say it's coming from?
12:47 JustinClift mark_m_: Our repo, or main EPEL, or ?
12:47 mark_m_ I'll check
12:47 kkeithley glusterfs isn't in EPEL.
12:48 JustinClift The concept in my question is "which repo?"  EPEL is just an example ;
12:48 mark_m_ > Installing:  glusterfs-fuse                                     x86_64                                     3.6.2-1.el6                                        glusterfs-epel                                      91 k
12:48 JustinClift ;)
12:48 JustinClift k
12:50 JustinClift Heh, I'd forgotten how slow VM's not-on-ssh can be. :/
12:50 hagarth JustinClift: are some of our slaves misbehaving?
12:50 JustinClift not-on-ssd
12:50 JustinClift hagarth: I haven't yet looked
12:50 * JustinClift looks
12:50 hagarth JustinClift: np, had to kill several test runs earlier in the day
12:50 JustinClift Wow, that's some backlog
12:51 JustinClift hagarth: I've been seeing quite a few hangs like this over the last few days: http://build.gluster.org/job/rackspace​-regression-2GB-triggered/7465/console
12:51 JustinClift eg Right at the very start of things
12:52 JustinClift hagarth: Is this a known problem we're trying to fix?
12:52 JustinClift And another one: http://build.gluster.org/job/rackspace​-regression-2GB-triggered/7467/console
12:52 JustinClift When I see this kind of thing, I disconnect the slave and reboot it.
12:53 JustinClift (safer, since job cleanup for cancelled jobs doesn't always work)
12:54 JustinClift And another http://build.gluster.org/job/rackspace​-regression-2GB-triggered/7475/console
12:54 JustinClift And another http://build.gluster.org/job/rackspace​-regression-2GB-triggered/7474/console
12:54 JustinClift And another http://build.gluster.org/job/rackspace​-regression-2GB-triggered/7473/console
12:55 JustinClift And http://build.gluster.org/job/rackspace​-regression-2GB-triggered/7477/console
12:55 JustinClift That's 6 out of 15 VM's hung
12:56 JustinClift I'd call that... not-optimal
12:56 mark_m_ hehe, I'd say the same
12:57 mark_m_ so - if we force our yum repo to /3.6/3.6.3/, that works, as does /3.6/3/6/2/, buut /LATEST/ is borked
12:57 mark_m_ ^^ /3.6/3.6.3/
12:57 mark_m_ ^^ and /3.6/3.6.2/
12:58 JustinClift mark_m_: So... my Centos 6.x VM (yum updated)
12:58 JustinClift I've just done curl -OL http://download.gluster.org/pub/gluster/glu​sterfs/LATEST/EPEL.repo/glusterfs-epel.repo into /etc/yum.repos.d/
12:58 rjoseph joined #gluster-dev
12:59 JustinClift mark_m_: Then done a yum install glusterfs-fuse
12:59 JustinClift mark_m_: Result: http://fpaste.org/215171/14298803/
12:59 hagarth JustinClift: seems like that.
13:00 JustinClift mark_m_: So, it doesn't _seem_ like there's a problem with the server's repo data or files there
13:00 JustinClift mark_m_: Maybe overwrite your .repo file with the one I curl'd above, and try that?
13:01 mark_m_ sure, we'll try
13:01 JustinClift k, let us know if it's still not happy after trying that :)
13:01 JustinClift hagarth: I can go through and fix these hung VM's, but we'll need to solve the hang cause
13:02 hagarth JustinClift: am not certain what's causing the hang .. can you check in dmesg or messages for anything suspicious?
13:02 JustinClift hagarth: I'm remembering something Jeff was saying about-rep pieces not being cleaned up after an aborted job
13:02 hagarth JustinClift: even devrpm builds were hanging..
13:02 JustinClift Interesting.
13:03 JustinClift If geo-rep has bits handing around after an aborted job, then maybe it can screw up pretty much any next type of job running after it
13:03 JustinClift We may need to add some pkill [stuff] type of thing to our Jenkins launch scripts
13:04 JustinClift I'm going to leave those hung ones hung for a bit, so they can be test bunnies for new "lets try and fix this" launch scripting
13:04 hagarth JustinClift: ok
13:08 mark_m_ when we use your file, we get lots of unresolved 3.6.2 version dependancy errors
13:09 JustinClift mark_m_: fpaste them somewhere?
13:09 JustinClift hagarth: Looking at slave33 for example, there are definitely old jobs which haven't finished
13:10 hagarth JustinClift: I see
13:21 mark_m_ Resolving Dependencies --> Running transaction check ---> Package glusterfs-fuse.x86_64 0:3.6.2-1.el6 will be installed Checking deps for glusterfs-fuse.x86_64 0:3.6.2-1.el6 - u looking for ('glusterfs', 'EQ', ('0', '3.6.2', '1.el6')) as a requirement of glusterfs-fuse.x86_64 0:3.6.2-1.el6 - u looking for ('rtld(GNU_HASH)', None, (None, None, None)) as a requirement of glusterfs-fuse.x86_64 0:3.6.2-1.el6 - u looking for ('libp
13:21 glusterbot mark_m_: -'s karma is now -1
13:21 mark_m_ glusterfs-fuse-3.6.2-1.el6.x86_64 requires: glusterfs = 3.6.2-1.el6 --> Processing Dependency: glusterfs = 3.6.2-1.el6 for package: glusterfs-fuse-3.6.2-1.el6.x86_64
13:21 JustinClift hagarth: Trying stuff now...
13:21 mark_m_ Potential resolving package glusterfs-3.6.2-1.el6.x86_64 has newer instance installed.
13:21 hagarth JustinClift: ok
13:22 mark_m_ Error: Package: glusterfs-fuse-3.6.2-1.el6.x86_64 (glusterfs-epel)            Requires: glusterfs = 3.6.2-1.el6
13:22 gem joined #gluster-dev
13:22 JustinClift mark_m_: What does rpm -qa|grep -i gluster show?
13:23 JustinClift hagarth: Added some pretty wide coverage pkill stuff to the launch bits in our jenkins jobs
13:23 JustinClift eg pkill -f regression.shg
13:23 JustinClift .sh
13:23 JustinClift pkill -f run-tests.sh
13:23 JustinClift pkill prove
13:24 soumya joined #gluster-dev
13:25 JustinClift Nope, still healing on afr/data-self-heal.t
13:25 mark_m_ I'm just rebuilding that host from a new raw vm, I'll check in a sec
13:26 JustinClift mark_m_: Sure
13:26 JustinClift s/healing on/hanging on/
13:28 kanagaraj joined #gluster-dev
13:29 kdhananjay left #gluster-dev
13:31 hagarth JustinClift: ok
13:31 kkeithley On my rhel6 box I just did a `yum downloader glusterfs\*` and got 3.6.3 RPMs
13:32 kkeithley from download.gluster.org
13:34 * JustinClift is suspecting there is something on mark_m_'s box which is compiled against 3.6.2, so is cauing issues with later :/
13:34 JustinClift Well, depends on 3.6.2
13:36 mark_m_ whats the dependancy plugin to use "yum download xxx"? I forget...
13:39 JustinClift mark_m_: Not sure what you mean?
13:40 JustinClift mark_m_: Are you guys using oVirt or QEMU?
13:46 dlambrig_ joined #gluster-dev
13:48 mark_m_ I mean, I have to do "yum install yum-utils" do I can execute "yum downloader glusterfs\* "
13:48 kotreshhr left #gluster-dev
13:55 JustinClift yumdownloader
13:55 JustinClift (one word)
13:55 dlambrig_ joined #gluster-dev
13:56 JustinClift mark_m_: This seems to be about right: sudo yumdownloader --resolve glusterfs-server glusterfs
13:58 rjoseph joined #gluster-dev
13:59 JustinClift hagarth: Any idea why this is breaking?
13:59 JustinClift http://build.gluster.org/job/g​lusterfs-devrpms/7701/console
14:00 JustinClift http://build.gluster.org/job​/glusterfs-devrpms/configure
14:00 JustinClift hagarth: It seems to be unhappy with the pkill of mock / rpmbuild... but that doesn't make sense to me since they shouldn't be running when the pkill fires off
14:01 * JustinClift adds a sleep statement
14:01 hagarth ok
14:05 kkeithley `rpm -q --whatrequires glusterfs-server`  Are we trying to find out what has a dependency on the glusterfs-server that's installed?
14:06 kkeithley sorry if I'm sounding discombobulated. It's because I am. Too many meetings
14:07 JustinClift kkeithley: Yours sounds more useful to me, for trying to see if there's something depending on 3.6.2 :)
14:13 wushudoin joined #gluster-dev
14:19 ndevos JustinClift: mock is in D-state, it tries to access an nfs-mountpoint on $localhost, but there is no nfs-server
14:19 ndevos JustinClift: and as a reminder, you can not kill processes in D-state :)
14:20 ndevos JustinClift: "cat /proc/$PID/stack" to see check for any nfs functions
14:21 ndevos JustinClift: kshlm aborted some tests earlier, but it seems that those left nfs-mountpoints behind...
14:21 JustinClift ndevos: Doesn't seem like it
14:21 JustinClift ndevos: There seems like weirdness in the scripting
14:22 ndevos JustinClift: check the PID of the (python) mock process, not the sudo one ;)
14:22 JustinClift ndevos: I commented the pkill mock lines, and the rest of teh pkill lines
14:22 JustinClift But it still auto-kills the dev-rpms job
14:22 ndevos sure, but it probably keeps the mock process around
14:23 JustinClift Ok.  But why would that auto fail the dev-rpm building script?
14:23 ndevos JustinClift: check if there is a nfs mountpoint (with 'mount') and see if there are "server not responding" messages in 'dmesg'
14:23 JustinClift Should I do umount -f on the mountpoints before killing mock?
14:23 ndevos I do not know why mock tries to access the nfs mountpoint...
14:23 anrao shyam: ping, had few doubts on logging framework migration
14:24 ndevos JustinClift: you can try to "umount -f", no idea if that comes through
14:24 JustinClift ndevos: Anyway, to explain further... pkill mock causes an auto-abort
14:24 JustinClift umount -f also causes an auto-abort
14:24 ndevos JustinClift: well, "pkill" does a regex match, it also kills the sudo process that executes mock
14:24 JustinClift But it's auto aborting jenkins controlling scripting
14:25 JustinClift Hmmm, so maybe it's sending a signal to itself somehow?
14:25 ndevos uh, where does the pkill come from?
14:26 JustinClift http://build.gluster.org/job​/glusterfs-devrpms/configure
14:26 JustinClift So:
14:26 JustinClift jenkins   5164  5155  0 11:17 ?        Sl     1:12  |           \_ java -jar slave.jar
14:26 JustinClift jenkins  17429  5164  0 14:26 ?        S      0:00  |               \_ /bin/sh -xe /tmp/hudson6568693517618497385.sh
14:27 JustinClift Because the jenkins script gets turned into /tmp/[tempfile].sh
14:27 JustinClift On the slave, then executed
14:27 ndevos JustinClift: that looks like a wrong approach to me, I think we should just reboot the slave when a job gets aborted
14:28 ndevos JustinClift: aborting jobs is done for many reasons, and it may not be possible to cleanup at all in some cases
14:28 JustinClift ndevos: That would be the better approach.  If you know how to make that work automatically, I'm all ears. :)
14:28 JustinClift Because ppl don't seem to be doing it.  Thus the hung jobs we have.
14:29 * ndevos is not a Jenkins expert, he would refer to JustinClift
14:29 JustinClift I'm not a Jenkins expert either, and have no desired to be
14:29 * JustinClift thinks Jenkins is pretty crap really :/
14:30 JustinClift I'm re-enabling lines in the new launch clause, to see which things are safe to kill or not
14:31 JustinClift pkill glusterd isn't
14:31 JustinClift Which seems strange, but ok
14:31 ndevos JustinClift: http://build.gluster.org/job/reboot-vm/configure has build-triggers, maybe those can be used for triggering-on-abort?
14:31 JustinClift Did we ever get that to work more than 1/4 of the time?
14:32 JustinClift :D
14:32 JustinClift ndevos: The concept of a trigger-on-abort though... it's worth seeing if it exists
14:33 JustinClift I'd just sort of assumed it doesn't.  But, it actually might.
14:34 ndevos JustinClift: it is possible to start a next job after the regression test, but I do not see how to pass the hostname on...
14:36 JustinClift Interestingly, the pkill -f statements aren't autoaborting the job
14:36 JustinClift -f seems to make a difference
14:36 JustinClift Hmmm
14:36 JustinClift Return code issues maybe
14:36 JustinClift Gah
14:37 JustinClift So, I've just changed the "pkill glusterd"  (which auto-aborts the build) to "pkill -f glusterd"... and the job is running ok.  No auto-abort.
14:37 JustinClift The next line that runs is this:
14:37 JustinClift ./autogen.sh || exit 1
14:38 JustinClift It sounds like that's catching a return code from the pkill and just deciding to no bother run autogen.sh
14:40 * JustinClift kicks a few more potential settings
14:45 JustinClift w t f
14:45 JustinClift "pgrep glusterd" causes it to auto-abort
14:48 dlambrig_ joined #gluster-dev
14:49 ashiq joined #gluster-dev
14:50 kkeithley FYI, static analysis of the release-3.7 branch running effective now.  That's clang-compile, clang-analyze, cppcheck, and coverity.   See http://download.gluster.org/pub/g​luster/glusterfs/static-analysis/   Anyone looking for "EASYFIX" bugs (and some not so easy to fix) can look here for things to do
15:03 kdhananjay joined #gluster-dev
15:04 JustinClift hagarth: Many of the hung VM's are now running again.
15:05 JustinClift hagarth: There should be _less_ hangs, though I doubt they're completely gone atm
15:13 shubhendu joined #gluster-dev
15:13 misc kkeithley: nice
15:23 kkeithley yes. nicer would be incremental reports that show whether day-over-day builds have added new issues
15:23 Manikandan joined #gluster-dev
15:23 Manikandan_ joined #gluster-dev
15:26 nbalacha joined #gluster-dev
15:32 JustinClift ep
15:32 JustinClift Yep
15:37 soumya joined #gluster-dev
15:37 ndevos kkeithley: just checking, but the ganesha xlator is client-side, right?
15:38 JustinClift kkeithley: Are you aware of the "make prep srcrpm" errors for 3.8 due to "file too long"?
15:39 JustinClift tardir=glusterfs-3.8dev && /bin/sh /home/jenkins/root/workspac​e/glusterfs-devrpms/missing --run tar chof - "$tardir" | GZIP=--best gzip -c >glusterfs-3.8dev.tar.gz
15:39 glusterbot JustinClift: GZIP='s karma is now -1
15:39 JustinClift tar: glusterfs-3.8dev/tests/bugs/glusterd​/bug-1121584-brick-existing-validati​on-for-remove-brick-status-stop.t: file name is too long (max 99); not dumped
15:39 JustinClift tar: Exiting with failure status due to previous errors
15:39 JustinClift Seeing that when stepping through build on master
15:39 JustinClift Not sure if it's a concern or not
15:42 ndevos JustinClift: I've seen those too, please send a patch
15:51 * JustinClift just emailed Gaurav who git told me to blame
16:34 kkeithley ndevos: dunno, that's a question for soumya.
16:35 kkeithley JustinClift: .../tests/bugs/glusterd/bug-1121584-brick-exis​ting-validation-for-remove-brick-status-stop.t     well, that's just wrong
16:35 kkeithley who did that?
16:36 kkeithley pfft. if I read all the way to the end.
16:38 kkeithley and tar has a lower limit than PATH_MAX? that seems borken
16:44 kkeithley hmm, there's a few others with long names, e.g. glusterfs-3.8dev/tests/bugs/glusterd/bug-765230-re​move-quota-related-option-after-disabling-quota.t  is 100 chars
16:45 kkeithley I'm all for descriptive names, but...
17:14 shyam joined #gluster-dev
17:25 soumya kkeithley, I have confirmed that its client-side xlator used for CLI
17:26 kkeithley so, it's the 'o' in `tar chof ...` that's limiting it to 99 chars.  That's from am__tar.  That comes from somewhere in automake or autoconf.  There's deep voodoo there.
17:27 kkeithley probably from /usr/share/aclocal-1.14/tar.m4:  [am__tar='$${TAR-tar} chof - "$$tardir"' am__untar='$${TAR-tar} xf -'],
17:28 kkeithley soumya: thanks.  btw, do you know if meghana wanted me to consolidate all three patches into a single change to review?
17:28 soumya kkeithley, preferably yes excluding add/delete_node part...
17:29 soumya kkeithley, we just want to make sure that we do not miss out changes we have done in that setup
17:29 kkeithley errr......
17:29 soumya scripts or resource-agents
17:29 soumya different patches are also fine as long as they are updated with the changes we did in saurabh's setup..
17:29 soumya just to make sure we do not miss out anything again..
17:30 shyam joined #gluster-dev
17:30 kkeithley yes, getting the changes to saurabh's setup is key.
17:30 soumya and Kaleb, we still seem to have the timing issues between dbus resource agent and IP failover :-/
17:30 soumya we thought we shall debug and fix that post the demo.. dint want mess with the setup till then :D
17:30 kkeithley yes, I saw that comment. I'll have to look at it again.
17:31 kkeithley right
17:31 soumya tmrw or day after ..we shall try to have one more 4-node setup with sources.. so that I can include my FSAL_GLUSTER patch too
17:32 soumya it may be useful for us while giving demo for upstream community on thursday
17:35 ashiq joined #gluster-dev
17:36 kkeithley okay, so if I'm to submit a new patch, or patches..  (just release-3.7 for the sake of discussion)   I've got 10318 (delete-node impl),  10317 (teardown /var/lib/nfs symlink), and 10359 (copy config, delete /etc/cluster/*).   How do you and meghana want to review those __plus__ the fixes from saurabh's setup?
17:37 kkeithley am I making sense? Am I asking the right question?
17:38 kkeithley should I just roll those all up into a single change-set and abandon the first three?
17:38 kkeithley I didn't really understand your answer above.
17:44 soumya kkeithley, I guess its fine the way they are...
17:45 kkeithley okay.
17:45 soumya kkeithley, I think we haven't pulled your delete_node and 10359 changes in Saurabh's setup..
17:45 soumya you think we should take those and run the tests again?
17:47 kkeithley you don't need them for what you're planning on demonstrating.  I'd wait 'til after the demo.  Or make sure you can easily revert to what's working now.
17:48 shyam joined #gluster-dev
17:52 soumya kkeithley, thanks..we shall then pull the changes post the demo
17:55 kkeithley (11:39:03 AM) JustinClift: tar: glusterfs-3.8dev/tests/bugs/glusterd​/bug-1121584-brick-existing-validati​on-for-remove-brick-status-stop.t: file name is too long (max 99); not dumped
18:01 kkeithley yeah, that's deep aclocal/automake/autoconf witchcraft.  aclocal/autoconf is defaulting to (tar) v7. Change the AM_INIT_AUTOMAKE to AM_INIT_AUTOMAKE(tar-pax) in configure.ac and you won't get file name is too long
18:02 kkeithley I'd think by now that we would be safe with POSIX 2001 portability
18:03 kkeithley See https://www.gnu.org/software/automake/manu​al/html_node/List-of-Automake-options.html
18:05 kkeithley ndevos: ^^^
18:05 JustinClift Interesting
18:06 JustinClift I emailed Gaurav about it (test author for that one), so he might rename it shorter too
18:06 JustinClift Though long + descriptive test names could be seen as useful
18:07 kkeithley there are several files that are too long. I guess I don't dislike the long names so much that I'd want to get rid of them.
18:07 kkeithley s/files/filenames/
18:08 JustinClift :)
18:08 kkeithley We should fix the _real_ problem, which is using a positively ancient tar format
18:08 JustinClift Yeah
18:08 JustinClift Should be ok on everything we run on yeah?
18:08 kkeithley not sure why aclocal/automake is still stuck in the dark ages
18:09 JustinClift I'm pretty sure autotools by themselves have extended the dark ages plenty ;)
18:09 kkeithley that's really the `make dist` at the top. The `make prep srcrpm` you ran is just running `make dist` at the top
18:09 JustinClift Ahhh cool
18:09 JustinClift It's been a long, long time since I walked through this area of stuff
18:12 shaunm_ joined #gluster-dev
18:14 kkeithley gnu tar defaults to "gnu" on RHEL and Fedora, probably almost every distro out there I'd guess.  Why automake would force it to use the original 1970 V7 format is just beyond comprehension. Does the author really think we need dist tarballs that can be read on 1970s era Unix boxen?
18:17 kkeithley want to file a bug?
18:24 JustinClift It's all yours ;)
18:29 ashiq joined #gluster-dev
18:44 JustinClift My brain really isn't absorbing this OAuth stuff for non-interactive apps.
18:45 JustinClift Think I'll call it a day.
18:45 JustinClift Have a good wkend all :)
18:50 shyam joined #gluster-dev
22:48 dlambrig_ joined #gluster-dev
23:02 dlambrig_ left #gluster-dev

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary