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