12:01:50 <ndevos> #startmeeting 12:01:50 <zodbot> Meeting started Tue May 19 12:01:50 2015 UTC. The chair is ndevos. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:01:50 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 12:01:58 <ndevos> #info Agenda: https://public.pad.fsfe.org/p/gluster-bug-triage 12:02:03 <ndevos> #topic Roll Call 12:02:12 * kkeithley_ is here 12:02:16 <ndevos> hi all, I hope we have a lot of people attending today! 12:03:02 <kkeithley_> me too 12:03:07 <ndevos> ... 12:04:02 <kkeithley_> hmmmm 12:04:10 * RaSTar here 12:04:22 * ndevos counts 3 12:04:40 <ndevos> hchiramm: ? 12:05:48 <ndevos> I guess we should move on, there are many bugs we need to triage 12:05:57 <RaSTar> ok 12:06:10 <ndevos> others can join in when they find their ways to this channel 12:06:36 <RaSTar> rafi1: joining? 12:06:44 <ndevos> #topic Group Triage 12:07:01 <ndevos> rafi1 is in a meeting, and might join later 12:07:04 <rafi1> RaSTar: yes i'm here 12:07:15 <ndevos> there is one bug waiting for bugs@gluster.org: https://goo.gl/CYpoFn 12:07:51 <ndevos> #info Bugs for 3.4 got a comment, asking for retesting and updating of the version in case the problem exists on newer versions 12:08:24 <ndevos> #info Bugs for 3.4 will get closed at the end of this month if there are no updates/corrections 12:08:52 <ndevos> #info 111 bugs were updated with the 3.4 re-confirm note 12:09:42 <ndevos> who wants to triage and clear the needinfo for bug 858732 ? 12:10:18 <kkeithley_> uhhh, well, what are we saying about it? 12:10:23 * ndevos opens the bug 12:10:56 <ndevos> seems like geo-rep: 0-glusterd: command failed: /usr/lib/x86_64-linux-gnu/glusterfs/gsyncd -c /etc/glusterd/geo-replication/gsyncd.conf --config-set-rx gluster-params xlator-option=*-dht.assert-no-child-down=true . 12:11:57 <ndevos> at least, the last message is... the 1st comment is not 12:12:39 <ndevos> kkeithley_: I'll update it, and ask for a new bug report filed against geo-rep 12:12:45 <RaSTar> there are many problems 12:13:01 <RaSTar> most basic, we don't guarantee anything after / is full 12:13:07 <ndevos> #info there are 40 untriaged bugs since the last meeting: http://goo.gl/WuDQun 12:13:13 <kkeithley_> and a supported version? 12:13:19 <RaSTar> peer list file gets truncated as we know 12:13:21 <ndevos> RaSTar: yes, that is the 1st issue 12:13:37 <RaSTar> I am not sure of other impacts on geo-rep 12:13:55 <RaSTar> Should a guide on how to replace peer in gluster help? 12:14:14 <ndevos> RaSTar: I think the last comment was added by someone else, and they thought they hit the reported bug (which they do not) 12:14:24 <RaSTar> yes.. 12:15:41 <ndevos> RaSTar: kp responded to the 1st comment, he should be aware of the problem - and it was reported a while ago already, so I think the issue is solved, but it needs a permanent fix in glusterd 12:16:54 <RaSTar> I remember atinmu writing a doc sometime back on how to replace peer. That could be a solution to this bug. The only preventive solution we have is to ask users to have file system heirarchy which does not get full. 12:20:45 <RaSTar> ndevos: what should we do if we want from info from the latest comment user? 12:21:02 <RaSTar> reply on same bug or ask him to file a new one. It might be a different issue 12:21:38 <ndevos> RaSTar: you can set "request additional information from" to the email address of the user 12:22:04 <RaSTar> same bug then, I will do that.. 12:22:23 <ndevos> RaSTar: I just updated that bug, please refresh :) 12:22:55 <ndevos> kkeithley_, RaSTar: do you know what release "pre-release" is referring to? master or some beta? 12:23:23 <kkeithley_> for which bz? 12:23:25 * ndevos would prefer to have the "pre-release" version dropped from the bugzilla selection 12:23:30 <kkeithley_> agreed 12:23:53 <ndevos> I see pre-release for 1220173 12:24:00 <ndevos> but there are ore 12:24:03 <ndevos> +m 12:24:20 * ndevos locks 1221045 12:24:44 <kkeithley_> needInfo: what release 12:24:46 <ndevos> wait, how can that bug land in the list? it is a RHGS one 12:25:11 <ndevos> ah, kkeithley_ fixed that one already :) 12:25:54 <kkeithley_> ;-) 12:26:05 <kkeithley_> 1221578 12:28:02 <ndevos> kkeithley_: that pre-release is an RFE :-) 12:28:18 <kkeithley_> 1220703 12:29:19 <kkeithley_> 1220713 12:29:20 <ndevos> 1222748 12:30:14 <ndevos> 1222614 12:30:37 <ndevos> RaSTar, rafi, hchiramm: are you triaging bugs too? 12:31:18 * RaSTar locks 1220021 12:31:19 <rafi> ndevos: my meeting just finished 12:31:32 * rafi is going throught he bug list 12:32:13 <ndevos> 1222678 12:34:37 * rafi locks 1220996 12:35:06 * RaSTar locks 1221473 12:36:56 * ndevos locks 1221980 12:37:56 * ndevos 1221605 12:40:04 * rafi locks 1221511 12:40:06 * ndevos locks 1222148 12:40:45 <rafi> jiffin: : Do you know any one working on this https://bugzilla.redhat.com/show_bug.cgi?id=1221511 12:43:02 * rafi locks 1221941 12:45:14 <rafi> ndevos: there are couple of nfs-ganesha bugs :) ? 12:45:50 <rafi> jiffin: ndevos: do u know any one working on this 1221941 ? 12:45:51 <ndevos> rafi: are they really ganesha bugs, or actually gluster* bugs? 12:46:02 <kkeithley_> 1221489 12:46:11 <ndevos> rafi: ganesha bugs should be filed against the NFS-Ganeshe product instead... 12:46:11 <rafi> ndevos: looks like ganesha bugs 12:46:42 <rafi> ndevos: 1221941 is actually crash on brick side 12:46:50 <kkeithley_> hold on.. Bugs with nfs-ganesha core and the gluster-fsal should be filed against NFS-ganesha product 12:47:09 <rafi> ndevos: might be because of nfs-ganesha 12:47:13 <ndevos> rafi: 1221941 seems like a bug in the upcall xlator 12:47:17 <kkeithley_> bugs in our supporting bits should be filed against gluster, nfs-ganesha component 12:47:19 <rafi> kkeithley_: let me check 12:47:33 <kkeithley_> upcall xlator is gluster, nfs-ganesha component 12:47:43 <kkeithley_> unless we have an upcall xlator component 12:48:22 <ndevos> kkeithley_: upcall is not nfs-ganesha only, if it is a sub-component of nfs-ganesha, that would be wrong 12:48:36 <ndevos> and yes, there is a upcall component 12:49:15 <kkeithley_> perfect 12:49:33 * rafi is going to read each and every comment in 1221941 and understanding the problem 12:49:38 <ndevos> sub-components are for making it difficult to file+track the bugs, I hope we do not need to use then 12:49:41 <ndevos> *them 12:49:50 <kkeithley_> 1221866 12:50:33 <ndevos> rafi: upcall tracks clients that are interested in a certain inode, once there is a cache-invalidation needed, upcall will send that notifiction to all the clients 12:51:00 <kkeithley_> 1219346 12:51:30 <ndevos> rafi: we use that in nfs-ganesha, because ganesha caches a lot of details (data and attributes), and different nfs-clients can use different nfs-ganesha servers for the same volume 12:51:43 <rafi> ndevos: upcall xlator loaded in server side ? 12:51:52 <rafi> ndevos: i mean brick graph ? 12:52:09 <ndevos> rafi: yes, it trackes all the clients and that can only be done on the bricks 12:52:40 <rafi> ndevos: yes, Make sense 12:53:50 * rafi locks 1221869 12:54:46 <ndevos> 1218479 12:55:23 <ndevos> ah, still on NEEDINFO 12:55:38 <ndevos> 1221560 12:57:46 <ndevos> 1219488 12:58:51 <rafi> ndevos: looks like a great one https://bugzilla.redhat.com/show_bug.cgi?id=1221737 12:59:07 * ndevos checks 12:59:29 <rafi> ndevos: from the fb :) 12:59:59 <ndevos> rafi: indeed, we spoke to them last week and asked to provide patches, even if not ported to the master branch 13:00:15 <ndevos> rafi: set the patch keyword, and add ravi + pk on CC :) 13:00:43 <rafi> ndevos: i heard that from RaSTar , great move 13:00:49 <ndevos> rafi: and maybe add a note, say "Thank you Richard!" 13:01:14 <rafi> ndevos: do you want to take this , you are friends :) 13:01:37 <rafi> ndevos: I'm adding this bug to my list to read it :) 13:01:40 <ndevos> rafi: no, go ahead :) 13:02:07 <ndevos> #chair rafi RaSTar kkeithley_ 13:02:07 <zodbot> Current chairs: RaSTar kkeithley_ ndevos rafi 13:02:19 <rafi> ndevos: feeling happy to see this :) 13:02:42 <ndevos> RaSTar, rafi, kkeithley_: I'm dropping off, could you continue and do a #endmeeting when you are done? 13:03:05 <ndevos> rafi: yes, it is really great, hopefully they will send more of their patches 13:03:24 <kkeithley_> I'm dropping off too. I have the Product Management meeting. 13:03:27 <kkeithley_> now 13:03:30 <rafi> ndevos: Should I add anything more on that ? 13:03:35 <kkeithley_> maybe end now 13:03:38 <RaSTar> ndevos: sure 13:03:59 <ndevos> kkeithley_: nah, rafi and RaSTar can decide when they want to finish 13:04:06 <kkeithley_> fair enough 13:04:14 <rafi> ndevos: :) 13:04:22 <ndevos> RaSTar, rafi: thanks! otherwise I'd be late for my lunch date ;-) 13:04:43 <ndevos> rafi: could you also send the meeting minutes and prepare the agenda when done? 13:05:10 <rafi> ndevos: I have a meeting with Dan once this is done 13:05:27 <rafi> ndevos: me or RaSTar will do that 13:05:52 <ndevos> rafi: thats okay, I can also send the minutes etc, just let me know what you decided to do :) 13:06:02 <rafi> ndevos: sure 13:06:08 * ndevos notes its past 15:00 here already, and he's *really* hungry 13:06:11 <rafi> ndevos: I will finish the list 13:06:19 <ndevos> rafi: thanks! ttyl 13:06:26 <rafi> ndevos: go ahead and have nice Lunch 13:12:24 <RaSTar> rafi: if you are not sure of which component the bug may be in 13:12:27 <RaSTar> what do you do? 13:12:34 <RaSTar> and whom do you set as owner? 13:13:42 <rafi> RaSTar: I usually add associated people to cc list if i'm not sure about the owner 13:14:05 <rafi> RaSTar: I don't know about component 13:14:17 <RaSTar> and let it be asssigned to bugs@gluster.org? 13:16:29 <rafi> RaSTar: yes 13:18:48 <RaSTar> ok 13:20:19 * RaSTar locks 1220348 13:21:04 * rafi locks 1221584 13:26:21 * rafi locks 1222238 13:29:22 <rafi> RaSTar: two more to go 13:29:28 <rafi> :) 13:30:32 * rafi locks 1221175 13:32:24 * rafi locks 1222898 13:33:47 <rafi> RaSTar: looks like we finished 13:34:32 <rafi> RaSTar: Do you mind to end the meeting 13:34:43 <RaSTar> rafi: go ahead and end 13:34:56 <RaSTar> #endmeeting