15:00:42 #startmeeting 15:00:42 Meeting started Wed Feb 5 15:00:42 2014 UTC. The chair is hagarth. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:42 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:54 who do we have here today? 15:00:56 * lalatenduM is here 15:01:03 * purpleidea says hi 15:01:29 #topic AI follow up 15:01:41 * jarrpa is here 15:01:55 * ira is here. 15:02:08 test owners to update spreadsheet about findings from test week - noticed purpleidea and lalatenduM updating the google doc 15:02:12 * raghu is here 15:02:31 we still are awaiting more testing feedback and should be able to drive it with beta3 15:02:58 sorting out gerrit for 3.4 and 3.3 was on me 15:03:00 hagarth, have not tested smb till now, but that is because of a different issue 15:03:29 * kkeithley_ is here 15:04:01 * ndevos _o/ 15:05:18 lalatenduM: yes, we could discuss that in the corresponding topic 15:05:18 kkeithley_: I haven't been able to sort out gerrit - was busy with a bunch of things over the last week. so will carry on this AI. 15:05:18 #action hagarth to look into sorting out gerrit for 3.3 and 3.4 15:05:18 johnmark has two AIs - not sure if he is around today 15:05:28 understood 15:05:38 let us move on 15:05:46 #topic GlusterFlow 15:06:00 it looks pretty. good job whoever that was 15:06:04 jclift_: ^ 15:06:06 GlusterFlow looks pretty neat, kudos to jclift_ 15:06:16 jclift_: what parts of glupy are broken atm? 15:06:20 jclift_, good job on FlosterFlow ! 15:06:54 jclift_: is in #gluster-dev noticing nfs is broken, with and without glupy 15:07:23 ndevos: I see, we can follow up with jclift_ on this one after the meeting. 15:07:25 hagarth: so, not so much glupy, rather nfs 15:07:45 ndevos: is there a quick summary of the issue? 15:07:51 k, here. :) 15:08:00 i used the bat signal 15:08:02 jclift_: great! 15:08:03 :) 15:08:11 purpleidea: thanks! 15:08:18 johnmark's talk is on right atm. 15:08:27 jclift_: can you explain the issue you're facing - very briefly? 15:08:27 jclift_: hangout thing? 15:08:30 He's looking at me weirdly when I look at the screen 15:08:48 purpleidea: Infrastructure.next conference in Ghent 15:08:51 oh 15:08:52 jclift_: you probably could check with him on his action items from last week ;) 15:09:20 hagarth: Now definitely isn't the right time. He's up the front, doing his new talk. (practising on us :>) 15:09:45 jclift_: now's the moment - just kidding :) 15:10:15 jclift_: can you briefly describe the problem you are encountering? 15:10:20 ndevos: Lets park the issue investigation until after this meeting is done. 15:10:38 hagarth: Gluster NFS server is sig 11 crashing with latest codebase 15:10:48 jclift_: sure, it wasnt me asking about it ;) 15:10:52 Core was generated by `/usr/sbin/glusterfs -s localhost --volfile-id gluster/nfs -p /var/lib/glusterd/'. 15:10:55 Program terminated with signal 11, Segmentation fault. 15:10:58 #0 x86_64_fallback_frame_state (context=0x7f68d13cfb30, context=0x7f68d13cfb30, fs=0x7f68d13cfc20) at ./md-unwind-support.h:58 15:11:01 58 if (*(unsigned char *)(pc+0) == 0x48 15:11:02 ^^ the crash 15:11:08 But really, lets do the meeting. 15:11:11 Sorry I'm late. 15:11:21 jclift_: right, let us add this as a blocker for 3.5. 15:11:38 ok, moving on. 15:11:41 #topic 3.5.0 15:11:55 we have had some feedback from the test week 15:12:16 lalatenduM has been able to run regressions and purpleidea has been able to run puppet-gluster with 3.5 15:12:41 I did basic testing of readdir-ahead and some users in the community have also reported perf. improvements with the xlator 15:12:45 although 3.5 feels different... i referenced one possible related bug 15:13:10 kudos to foster for readdir-ahead :) 15:13:22 purpleidea: the bug in the peer state machine? 15:13:25 :) 15:13:29 hagarth: yeah 15:13:57 but unrelated to that, the peering state seems to behave differently in 3.5 (vs. 3.4) 15:14:09 state machine* 15:14:28 purpleidea: interesting, I don't recall that part of the code changing much between 3.4 and 3.5 15:15:01 lalatenduM: would you want to briefly mention your feedback on tests that you did? 15:15:11 hagarth, sure 15:15:39 I did some testing on add-brick , remove-brick and rebalance and it was working fine 15:15:55 I bug I had found in beta1 is resolved now 15:16:04 s/I bug/ the bug/ 15:16:12 lalatenduM: good to know! 15:16:16 I have marked the bug as verified 15:16:37 lalatenduM: thanks 15:16:51 msvbhat: is there any feedback from your testing? 15:17:29 hagarth: I didn't do much testing with geo-rep. But the hooks scripts need to be part tarball 15:17:50 I did source installation and hook scripts were missing 15:18:02 msvbhat: maybe we should open a bug for that? 15:18:16 hagarth, same for Samba hook scripts 15:18:19 hagarth: Yeah. I will open a bug. Will check once with the rpms as well 15:18:40 msvbhat: cool, let us use the same bug for packaging both samba/geo-rep hook scripts. 15:19:00 the plan is to do beta3 by the end of this week 15:19:29 hagarth: I will try and run some more tests by tomorrow evening. 15:19:37 if the source install doesn't install them, they won't magically be in the rpm. 15:19:41 and open up one more test week window (hopefully the final one) before the release. 15:19:52 someone should probably test nfs too, just to make sure it's not only jclift_ hitting these problems 15:20:02 msvbhat: thanks 15:20:35 ndevos: agree, I will try to run basic fs-sanity tests on nfs later this week. 15:21:07 ok, sounds good to me 15:21:11 kkeithley_: yeah, make dist needs to include those scripts. 15:21:47 beta3 should contain all quota and geo-replication backports as well. 15:21:52 kkeithley_, hagarth we need to revisit samba hook scripts too, if we can include them 15:22:03 lalatenduM: yes 15:22:22 yes, all of those 15:23:12 so to summarize status of 3.5, some more testing is needed and we will aim to have that covered with beta3. A few known bugs need to be fixed. 15:23:18 hagarth: I'm not sure about the current state of documentation for geo-rep. But we need to include the upgrade steps from 3.4.x to 3.5 15:23:36 msvbhat: right, can we open one more bug for tracking that please? 15:23:45 does the 3.5 geo rep include the 1 geo-rep daemon per replica set thing? 15:23:56 hagarth: Sure. Will open a new one 15:24:10 purpleidea: yes 15:24:16 msvbhat: thanks 15:24:20 hagarth: are there docs on this somewhere? 15:24:58 purpleidea: I need to look that up. Will let you know post this meeting. 15:25:06 hagarth: thanks! 15:25:38 lalatenduM: do you want to talk about samba vfs plugin? 15:26:14 hagarth, yes 15:26:14 ??? upstream or downstream vfs plug-in? 15:26:16 Can we provide the glusterfs-vfs plugin for Samba in a brinary packaged format e.g. a .rpm( rpm based distros and .deb (for debian distros)? so that if anybody want to use libgfapi+Samba then he/she does not have to compile Samba with glusterfs vfs plugin. 15:26:30 kkeithley_: upstream only here :) 15:26:31 we already do for Fedora 15:26:35 kkeithley_, upstream :) 15:26:52 Fedora 20, 21 has samba 4.1.3 with the vfs plugin 15:26:56 kkeithley_, what about centos or debian distros? 15:27:16 I've built samba 4.1.3 with the vfs plugin for Fedora 19 and 18. It's on download.gluster.org 15:27:24 kkeithley_, yup 15:27:56 building samba-4.1.3 for el6 is hard, and I'm working on el7 in my (copious) spare time. 15:28:28 kkeithley_, what should we do for centos or other distros , jarrpa ira^^ 15:28:32 Debian is even harder 15:28:57 is Samba-3.x going to be easier? 15:29:00 lalatenduM: We should ping the debian maintainer for Samba, I believe he is pretty active. 15:29:41 It'd be best if they owned it, their way. :) 15:30:04 lalatenduM, kkeithley_, ira: I believe CentOS would need RHEL to package it? If so, RHEL needs a customer BZ on bugzilla.redhat.com to show demand for this inclusion. 15:30:24 kkeithley_, hagarth ira , I think the vfs module is built when we build Samba with it. Can we make it independent , so that we can just build vfs plugin? 15:30:37 The reason el6 is hard is because it's still init.d (versus systemd) and I just haven't made time to cherrypick the init.d scripts from whatever version there is for that and build 4.1.3 with them. 15:31:01 lalatenduM: Even the upstream 3.6.9 VFS plugin still needs a Samba source tree. 15:31:40 ok, if providing a build is hard - can we provide precise instructions if somebody wants to install from source? 15:31:48 RHEL and CentOS ship 3.x. EPEL won't ship it because it's in RHEL. Anything we do for RHEL and CentOS will be for download.gluster.org 15:32:44 the plugin is in the RHS samba package, just not in the normal version 15:33:01 ndevos, yup 15:33:10 ira, jarrpa: would it be easy enough to provide instructions for building from source? 15:33:11 ndevos: indeed, but.... 15:33:45 Well, we can always just rebuild samba from the same sources and just pluck out the module. 15:34:06 Anyway, getting newer bits into CentOS is something we're working on. I just need cycles to get init.d scripts for 4.1.3 on RHEL 15:34:12 As long as we use the same version of samba, it'll be fine, I believe. 15:34:30 kkeithley_: Thank you. 15:34:58 ira, the vfs-code we hosted in forge I think is for Samba 4 , is it correct kkeithley_ jarrpa 15:35:07 lalatenduM: Incorrect 15:35:08 lalatenduM: 3.6 only. 15:35:14 ok 15:35:19 Yes, everything I'm talking about is 4.1.3 15:35:28 4.1+ is all in tree. 15:36:03 We're not acting on Samba 4.0 AFAIK. 15:36:22 So if Samba 4.1+ gets packaged, the VFS module is included already. 15:36:29 jarrpa, correct 15:36:54 And it won't randomly pull in all of gluster? :) 15:37:11 ira: 4.0 is what's in Fedora 19 "out of the box" . Hence the reason we have 4.1.3 for F19 on download.gluster.org. 15:37:23 ira: That's up to the packagers. :) 15:37:25 The vfs is in a separate RPM. 15:37:35 kkeithley_: Bravo! 15:37:44 Is there any demand to have the VFS module neatly packaged for older versions of Samba, e.g. as found in RHEL 6.4/6.5? 15:37:59 Yeah, I didn't do that. Whoever owns the Fedora samba package did it. 15:38:00 jarrpa, yes 15:38:26 jarrpa, so that it would be easier to run Samba+vfs in centos 15:38:56 lalatenduM: Those folks should create a RH BZ for it, then. I've already made one for 6.6, but we need outside pressure to get it included in released versions. 15:39:20 kkeithley_, yup it was #asn , we (as, jarrpa and me ) had discussion around it 15:39:33 s/as/asn/ 15:40:12 ok folks - let us move on from here. who will own follow up on this? 15:40:32 jarrpa, not sure if I understand this correctly, however we can talk offline abt it 15:40:39 lalatenduM: Sure. 15:40:53 So I guess lalatenduM and I 15:40:58 jarrpa: thanks 15:41:05 hagarth, ok 15:41:14 #action jarrpa and lalatenduM to follow up on samba packaging for CentOS 15:41:27 #topic 3.4 15:41:43 https://bugzilla.redhat.com/show_bug.cgi?id=1060259 is the tracker bug 15:41:46 Bug 1060259: unspecified, unspecified, ---, kkeithle, NEW , 3.4.3 tracker 15:42:56 kkeithley_: cool, thanks 15:43:09 the diff between 3.4.2-release and $head of release-3.4 branch is small. Once I get the magic "submit patch" button then I'll do (at least) the one or two patches that hagarth has mentioned to me and run an alpha release 15:43:10 That reminds we. Me need to rename glupy/gluster.py to glupy/[something.py] in 3.4 codebase. 15:43:19 * jclift_ needs to write up a BZ 15:43:52 Having it called gluster.py is a name conflict in Python when doing 'from gluster import *' <-- gets the libgfapi stuff instead 15:44:06 kkeithley_: sure, I'll try my best to sort out gerrit this week. 15:44:06 jclift_: is glupy working well, and packaged/included with the centos rpm's? 15:44:10 s/Me need to/We need to 15:44:37 hagarth: I understand you've been pretty busy. ;-) 15:44:41 jclift_: btw 'doing from gluster import *' is considered bad practice i think 15:44:45 purpleidea: I haven't looked at the CentOS rpms in ages. I just build from source a lot. 15:45:11 purpleidea: It could be. I'm not a Python expert. 15:45:43 it was just an fyi, because doing that makes a mess all over your namespace 15:45:57 kkeithley_: :) 15:46:01 We'll probably need to update some code then. :) 15:46:29 johnmark: You here? 15:46:51 jclift_: will you take care of renaming in glupy? 15:47:12 Yeah, action me 15:47:19 * ndevos can assist jclift_ if needed 15:48:01 #action jclift_ to address renaming with glupy 15:48:02 ok folks, moving on 15:48:17 #topic 3.6 and 4.0 15:48:31 in the interest of time, I think we need to club discussion on 3.6 and 4.0 15:48:39 we briefly alluded about this last week 15:48:51 http://www.gluster.org/pipermail/gluster-users/2013-November/038050.html 15:48:56 #link http://www.gluster.org/pipermail/gluster-users/2013-November/038050.html 15:49:12 given the plan to revamp some of our core infrastructure pieces with 4.0, what should be pushed out from 3.6 to 4.0? 15:49:14 i think ^ this is along those lines 15:49:39 hagarth: snapshot is scheduled for 3.6 right? 15:49:43 msvbhat: right 15:49:55 though it needs a feature page to be added in #link - http://www.gluster.org/community/documentation/index.php/Planning36 15:50:15 I think we can push out thousand node glusterd to 4.0 15:50:23 I kind of hate to do it, but I agree. 15:50:33 I have to go. Conference over, we're all clearing out. 15:50:42 jdarcy: are there other things that we need to consider from the list that we have? 15:51:20 I really don't think we can afford to push data classification/tiering out any further. DItto for SSL improvements (which are small anyway). 15:51:36 jdarcy: agree, we absolutely need data classification 15:51:40 If anything big had to go, I'd say NSR, though that makes me sad too. 15:51:47 NSR? 15:51:57 Nifty Super Replication 15:52:07 purpleidea: http://www.gluster.org/community/documentation/index.php/Features/new-style-replication 15:52:08 jdarcy: we could still consider NSR as opportunistic for 3.6 I think. 15:52:37 As opportunistic, yeah, but with the other big items such as data classification and snapshots in there I don't think we can commit to it. 15:52:49 folks, please go ahead and submit proposals for 3.6 sooner than later. 15:53:05 jdarcy: yeah 15:54:09 I will also attempt getting discussions started on 4.0 15:54:41 anything more on 3.6 and 4.0? 15:55:03 guess not, moving on 15:55:11 #topic open discussion 15:55:27 jdarcy: I presume you would not be available next week for the meeting? 15:55:40 Next week is OK. Week after is FAST. 15:56:09 jdarcy: ok, we can consider picking up a topic on 4.0 and also chat with xavih about his proposal on gluster-devel 15:56:11 if any gluster devs have a bit of time to help me with the algorithms in: http://www.gluster.org/pipermail/gluster-users/2013-November/038050.html it would be really appreciated 15:56:31 purpleidea: let us note an AI ;) 15:56:46 #action gluster developers to provide feedback on #link http://www.gluster.org/pipermail/gluster-users/2013-November/038050.html 15:56:49 jenkins seems to be mostly healthy again! Or is it? 15:57:01 hagarth: thanks 15:57:06 kkeithley_: not quite, there is a race which can crop up any time 15:57:17 ah, roulette? 15:57:28 just adding to the regression backlog 15:57:31 kkeithley_: am still looking into that. happens most times with 6.5, not on F19 15:57:52 should we just drop mount-options.t till this race is addressed? 15:57:58 hagarth: Do you have a build with the signature of the race? 15:58:41 ira: a simple way to do that would be to comment sleep 40 in mount.t and run prove tests/basic/mount-options.t tests/basic/mount.t tests/basic/nufa.t 15:58:59 nfs mounting in mount.t and nufa.t are bound to fail 15:59:17 Can we comment out the tests that have the race? 15:59:49 kkeithley_: that is the problem - I haven't been able to figure which test or set of tests in mount-options.t to trigger this race? 16:00:09 oh, okay 16:00:28 should we drop mount-options.t, address this race and then bring it in again? 16:01:00 or do we continue the same way? 16:01:10 Since mount-options isn't in 3.5 it seems like a reasonable thing to do 16:01:14 +1 for dropping it 16:01:46 ok let us do it then. 16:01:52 anything else for today? 16:01:53 * jdarcy abstains, due to an uncharacteristic lack of an opinion. 16:02:16 jdarcy: abstain ~= +1 :) 16:02:28 thanks folks, talk to you again next week. 16:02:33 C ya! 16:02:33 #endmeeting