15:00:25 #startmeeting 15:00:25 Meeting started Wed Feb 12 15:00:25 2014 UTC. The chair is hagarth. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:25 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:42 who do we have here today? 15:01:02 * jarrpa is here 15:01:08 * xavih is here 15:01:43 cool, let us get started. I suspect a few others are here but passive atm. 15:01:56 #topic AI follow up 15:02:24 gerrit for 3.3 and 3.4 has been sorted out - kkeithley is able to merge patches to those branches 15:02:43 * kkeithley is here 15:02:53 * ira is here 15:03:09 kkeithley has got samba packaging for CentOS - so we seem to be good there 15:03:27 jclift_: any progress on glupy renaming issue? 15:04:04 purpleidea did want some feedback on #link http://www.gluster.org/pipermail/gluster-users/2013-November/038050.html from gluster developers - we seem to have missed that. 15:04:20 so let us carry forward the AI. 15:04:21 * jdarcy will do that today. 15:04:25 jdarcy: thanks! 15:04:53 #topic 3.5.0 15:05:16 we got beta3 out - geo-replication and quota seem to be mostly covered with this release 15:05:48 that has been a relief - we can get quite aggressive from here in getting upto 3.5.0 GA 15:06:20 johnmark has planned a test week for 3.5 starting today and we have a weekend test event in the Red Hat Bangalore office. 15:06:56 based on the outcome from these test fests, we should be able to release 3.5.0 soon 15:07:06 W00t. 15:07:42 I will carve out more releases as and when patches get merged into release-3.5, so there might be a spike in the number of release candidates from here. 15:08:38 if you notice any blockers to 3.5.0 GA, please add it to the release tracker - #link https://bugzilla.redhat.com/show_bug.cgi?id=1049981 15:08:41 Bug 1049981: unspecified, unspecified, ---, vbellur, NEW , 3.5.0 Tracker 15:09:00 any questions on 3.5.0? 15:09:25 guess not, let us move on 15:09:33 #topic 3.4.0 15:09:36 http://review.gluster.org/6854 15:09:46 we want this in 3.4 right? 15:10:08 would someone review it so I can merge it and make a 3.4.0alpha1 release? 15:10:18 3.4.3alpha1 release 15:10:19 kkeithley: yes, that is right. It is a backport, I will do that after this meeting. 15:10:50 kkeithley: that would be great, let us get it going. 15:10:50 I looked for it on master, but didn't see it. Not with that BZ 15:11:37 commit b880b6b2908ad4e4afc8e26613bd0db8f0b28750, BUG: 969461 15:11:43 kkeithley: this has possibly not made it to master in anticipation of the refactored AFR coming in 15:11:52 but this patch is present in release-3.5 15:12:05 and is essential for all releases that we support. 15:12:06 here 15:12:43 johnmark: cool, slight OT - would you be sending out details of test week for 3.5 today? 15:12:44 okay, at this point I'll wait for the +2 review 15:12:51 hagarth: yup yup 15:12:52 kkeithley: ok 15:12:58 any particular pieces we shoudl focus on? 15:13:01 I presme I have privs to set a tag in the release-3.4 branch 15:13:02 geo-rep is one 15:13:07 presume 15:13:11 johnmark: quota would be another. 15:13:16 hagarth: ok 15:13:23 * johnmark goes to feature pages 15:13:24 kkeithley: if not, let us sort it over. 15:14:11 there is one more candidate for inclusion in 3.4.3 15:14:20 https://bugzilla.redhat.com/show_bug.cgi?id=1041109 15:14:22 Bug 1041109: urgent, unspecified, ---, csaba, NEW , structure needs cleaning 15:14:41 we need to pay some attention to that. 15:14:52 If I get 3.4.3alpha1 out — which I should — then we can test both 15:15:03 sweet 15:15:07 kkeithley: right 15:15:30 cool, anything else on 3.4? 15:15:46 will this be included ? https://bugzilla.redhat.com/show_bug.cgi?id=859581 15:15:47 Bug 859581: high, unspecified, ---, vsomyaju, ASSIGNED , self-heal process can sometimes create directories instead of symlinks for the root gfid file in .glusterfs 15:16:15 xavih: reproducible? 15:16:30 johnmark: there is a test script to reproduce it 15:16:31 xavih: it's in the 3.4.3 tracker 15:16:42 kkeithley: ok 15:16:59 xavih: I think it would be good to review and get it into all branches - I see that you have submitted backports to all branches. 15:17:00 may not get to it for 3.4.3alpha1 though 15:17:07 there is a patch for review, but no reviews yet 15:17:31 hagarth: yes 15:17:51 xavih: I will pick that up and nudge others who are relevant to it. 15:18:00 hagarth: ok, thanks 15:18:18 #action gluster devs to review patches for #link https://bugzilla.redhat.com/show_bug.cgi?id=859581 15:18:21 Bug 859581: high, unspecified, ---, vsomyaju, ASSIGNED , self-heal process can sometimes create directories instead of symlinks for the root gfid file in .glusterfs 15:18:30 any other questions on 3.4? 15:18:46 guess not, let us move on. 15:18:55 :) 15:18:59 #topic 3.6 15:19:30 There have been a few features proposed over the last week (mostly carried over from 3.5 planning) 15:19:41 I also have got a few requests to move the date by a week 15:19:51 the original proposal freeze is tomorrow 15:20:01 hrm 15:20:07 if everybody feels it is ok, we can move the entire schedule by a week 15:20:12 thoughts? 15:20:12 hagarth: right 15:20:15 hagarth: +1 15:20:22 impossible to meet proposed deadline 15:20:27 If we're going to move, I suggest two weeks. 15:20:40 On the theory that you guys might come up with something in BLR. 15:20:45 jdarcy: good point 15:20:53 plus many US-based people are on break 15:21:02 jdarcy: ok, how about this - we move the schedule by 2 weeks 15:21:22 and have the proposal review meeting as part of this meeting 3 weeks from now? 15:21:44 SGTM 15:22:01 we get a break? 15:22:29 kkeithley: I mean, kids in school are out next week 15:22:33 doesn't pertain to you :) 15:22:44 #action hagarth to move schedule by 2 weeks and schedule a proposal review meeting for 3.6 on 5th march. 15:22:50 I'm not exactly taking a break, but unavailable anyway due to FAST. 15:23:17 this will also give us enough buffer to push 3.5.0 out 15:23:48 cool 15:24:09 ok, any more questions on 3.6? 15:24:31 guess not, let us move on. 15:24:34 #topic 4.0 15:25:05 there have been some comments in the google doc page that jdarcy set up for 4.0 15:25:17 some of them call for more discussion 15:25:39 I wonder if we should pick up those from the doc and convert them to mailing list discussions 15:26:17 or if we should continue discussions in the google doc itself? 15:26:31 ISTRC that Avati was amenable to creating a second draft as a way to kick off that discussion. 15:27:14 jdarcy: yeah, let me ping him on that one. 15:28:14 we have a lot of ground to cover there and need to evolve a good plan to develop 4.0 as a globally distributed community. 15:28:41 Also from last week's mtg, there are some new pieces (esp. around scalability) that need to be incorporated. 15:29:20 jdarcy: right, let us try to get a v2 of the document out that incorporates all these comments. 15:29:35 and that can be the basis for further discussions on 4.0. 15:30:06 any topics related to 4.0? 15:30:32 guess not, let us move on. 15:30:48 #topic discussion on xavih's proposal 15:30:56 #link http://lists.gnu.org/archive/html/gluster-devel/2014-02/msg00004.html 15:31:14 * purpleidea is joining late, sorry 15:31:20 xavih: would you mind summarizing the proposal briefly here for the benefit of folks who might have not read it? 15:31:28 I have a patch that might relate to this. http://review.gluster.org/#/c/6978/ 15:32:11 basically it's a way to give clients temporary full control over inodes, so that they do not need to constantly send requests to the bricks 15:32:17 It's only a tiny bit of infrastructure, but might be useful for prototyping the consistency IPC. 15:32:35 jdarcy: looks like an interesting idea to pursue 15:32:39 interesting... 15:32:58 this also substitute the inodelk and entrylk fops 15:33:10 One possibility is to use it for "long polling" to get server-to-client notifications. 15:33:18 and allows a more aggressive cache implementation on client side that will significantly improve performance 15:33:50 jdarcy: right 15:34:38 the server-to-client notifications could be used for invalidation of anything that the client exclusively thinks it has control over 15:34:44 ndevos made me aware that there is something very similar in NFSv4 called delegations and callbacks 15:35:00 Maybe we should schedule a separate IRC meeting to discuss ideas esp. around how to handle failures in such a system. 15:35:12 xavih: SMB has similar concepts... 15:36:13 jdarcy: sounds like a good idea .. any preferred day and time for that meeting? 15:36:32 This time tomorrow? 15:36:43 Should work. 15:36:45 ira: so something that all distributed FS try ot implement? 15:36:55 ok 15:37:00 jdarcy: I have a conflict, but I think I can be on here too. 15:37:08 johnmark: Everyone has a way to do client side caching of various forms. 15:37:12 johnmark: Yeah, it was common even when we did it in MPFS (1999-2000 or so). 15:37:13 jdarcy: is there a way for us to do this such that we are enabling or setting a standard for how this should be done in all DFS? 15:37:36 maybe that's a question for later, after we actually have an implementation :) 15:37:48 johnmark: Actually, that's a question, I'm looking at some... 15:37:59 ira: ah, ok 15:38:03 johnmark: there already are implementations - we might borrow a lot of ideas from all places :) 15:38:11 johnmark: Though really in the NFS/SMB space, clearly, it goes to all spaces. 15:38:11 I think each DFS tends to have enough different data objects on which this must operate, and different semantics across those objects, that it would be hard to standardize. 15:38:12 hagarth: of course :) 15:38:26 jdarcy: that's the answer I was looking for 15:38:46 jdarcy: You'll never standardize it across Gluster and Ceph. But within Gluster... 15:38:51 But absolutely, we can and should borrow ideas from those (sometimes ourselves) who have gone before. 15:39:13 Even that standardization is a large effort. 15:39:36 To make sure, you can support all the strange semantics, people will want :/ 15:40:04 So, here 10am EST tomorrow? At least Xavi, Ira, Vijay seem interested. 15:40:23 zimbra invite? 15:40:24 jdarcy: sounds good to me 15:40:29 I would love to be here to breathe in your air, but I will unfortunately be heading to the airport for vacation :( 15:40:35 kkeithley: I can do that. You want in? 15:40:42 sure 15:40:43 johnmark: vacation! 15:40:48 purpleidea: I know, right? 15:41:07 jdarcy: we could also CC gluster-devel as an optional invitee 15:41:08 johnmark: you need to send a fax first (remember?) 15:41:16 * jdarcy actually volunteered for two AIs. Mark the date. 15:41:17 purpleidea: yes. I remember :) 15:41:20 lol 15:41:30 jdarcy: lol 15:41:48 ok, let us move on 15:41:55 #topic open discussion 15:41:59 1. GSOC 15:42:11 vipulnayyar: are you around? 15:42:19 2. One question about if there isn't a better way to handle: https://gluster.org/pipermail/gluster-users/2014-February/039039.html 15:42:30 (maybe in new style replication) 15:42:41 we have 2 days, 3 hours remaining for the organization deadline 15:42:41 yes I'm here. 15:42:59 vipulnayyar: welcome 15:43:02 johnmark: can you help us with meeting the organization deadline? 15:43:24 hagarth: yes. pretty sure we can come up with two or three solid ideas and submit gluster.org as an organization 15:43:37 hagarth: I will take care of that before I leave 15:43:45 ...along with purpleidea's hotel fax :) 15:43:54 johnmark: great 15:44:14 vipulnayyar: do feel free to propose glusteriostat - we will provide any necessary assistance. 15:44:21 hagarth: we should submit puppet-gluster of a GSOC and i'll apply :P 15:44:43 purpleidea: Not sure if NSR would be any different. It's a transport phenomenon, supposed to balance between fast failure detection and false alarms due to mere slowness. 15:44:47 johnmark: you can pick up ideas from our backlog 15:45:14 Thanks hagarth . 15:45:15 jdarcy: okay, well for whichever replication, a solution for that problem would be appreciated for sysadmins, i think. 15:45:35 * jdarcy will reply further on the ML. 15:45:36 one question on the trello backlog - I am planning to make it visible to everybody with edit rights to org 'GlusterFS'. is everybody fine with that? 15:45:45 +1 15:46:27 done - #link https://trello.com/b/mczS4DKw/glusterfs-backlog is now world readable. 15:46:39 one less AI to carry further ;) 15:46:53 hagarth: ok 15:47:12 hagarth: +1 15:47:24 I will also send a note to mailing lists about our backlog. 15:47:31 vipulnayyar: I'll create a page for us ot submit ideas 15:47:36 hagarth: thanks 15:47:50 sure, thanks johnmark 15:48:03 any more questions on GSoC? 15:48:24 nope. pretty straightforward 15:48:30 ok, moving on to Storage SIG in CentOS 15:48:46 johnmark: would you want to provide some context on this one? 15:49:20 hagarth: sure 15:49:22 one sec 15:49:45 CentOS has the concept of "SIG"s == special interest groups 15:49:58 basically, it's a way of providing a shared pool of packages for other projects to make use of 15:50:21 Like EPEL, but more focused? 15:50:44 so, for example, there's a cloud SIG, and there are some base packages not in regular CentOS that some projects need, such as openstack, euca, et al 15:50:52 kkeithley: right 15:51:07 so the ceph project started the storage SIG to do the same thing 15:51:29 and we should probably participate to make sure that packages on CentOS can be used for full GlusterFS features 15:51:43 for example, we need an updated libvirt and qemu 15:51:55 and a samba compiled with our vfs plugin 15:52:01 so those sorts of things 15:52:09 johnmark: maybe G4S, pmux et al too 15:52:25 hagarth: johnmark: *cough* and a puppet-gluster package... 15:52:43 you can see the storage SIG proposal here: http://grokbase.com/t/centos/centos-devel/141nvt6rde/storage-sig-proposal 15:52:44 purpleidea: I left out puppet-gluster intentionally ;) 15:52:52 purpleidea: lol... yes! of course 15:52:57 hehe 15:53:01 johnmark: should we have a ML discussion to arrive at the list of packages? 15:53:11 hagarth: right - except those would not be essential for all storage build 15:53:18 johnmark: ok 15:53:22 those would be specific ot a gluster distribution, which we can submit at any time 15:53:31 I'm happy, e.g. to do things like build gluster, samba4+gfapi, ganesha+gfapi, for the SIG, but what's the first step? 15:53:39 johnmark: ok, got it. 15:53:47 but read through the storage SIG proposal, and it would be great if one of our devs could respond to that thread 15:53:58 or QE folks... 15:54:06 doh... where's Lala? 15:54:13 johnmark: lalatenduM is interested - he could not join this meeting today - I will sound him tomorrow. 15:54:19 hagarth: thank you 15:54:41 #action hagarth to talk to lalatenduM about storage SIG 15:55:07 kkeithley: I will ask lalatenduM to mark you when he responds. 15:55:25 anything more on this topic? 15:55:28 kkeithley: that does bring up the question of what a gluster distro looks like, however 15:55:38 for 3.5, what all do we want to include in the builds? 15:55:46 johnmark: we probably should propose a gluster SIG ;) 15:55:51 can we include g4s, pmux, ghadoop, puppet-gluster, etc? 15:55:59 hagarth: haha... perhaps :) 15:56:07 johnmark: ^glupy ? 15:56:12 I'd like to get g4s into Fedora first 15:56:13 but I think they'll just ask us to submit those project 15:56:18 purpleidea: yup, another one 15:56:28 er... submit those packages individually, which is fine 15:56:48 johnmark: it would be great to have a single bundle of all reasonably mature projects from forge 15:56:59 hagarth: we can aat least start the conversation onthe mailing list like this "we have a bunch of packages we want to put into centos - how can we do that?" 15:57:07 hagarth: exactly 15:57:21 (there is also copr, which is a good place for new packages) 15:57:23 and it would be good to start getting them into other distros, as well 15:57:23 johnmark: yeah, let us start that - would you take the lead on that? 15:57:28 johnmark: right 15:57:42 hagarth: indeed. I've been talkign to the centos guys about it anyway - just need to push something on the list 15:57:46 I guess I should whine on devel@fedoraproject.org about the unresponsive reviewer 15:57:51 johnmark: cool! 15:57:52 purpleidea: copr? 15:57:56 lol 15:58:13 johnmark: https://fedorahosted.org/copr/ 15:58:18 ok - one more topic for today. 15:58:22 like ppa's for fedora 15:58:33 3. 3.3 EOL ? 15:58:42 +1 15:58:57 +1 for -1 15:59:07 should we EOL support for 3.3 once 3.5.0 is out? 15:59:41 if it means I can duck out of 3.3.3 then +1 15:59:49 Absolutely. Supporting old/current/new is quite enough IMO. 16:00:03 kkeithley: :) 16:00:28 ok, I think we have our answer. 3.3 to be EOL once 3.5.0 is out. 16:00:37 anything else for today? 16:01:04 figure not, thanks everybody and talk to you all next week. 16:01:07 #endmeeting