15:02:01 <JustinClift> #startmeeting Weekly Gluster Community Meeting
15:02:01 <zodbot> Meeting started Wed Apr 30 15:02:01 2014 UTC.  The chair is JustinClift. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:07 * kkeithley is here
15:02:17 * ndevos is attending
15:02:24 * hagarth is here
15:03:06 <JustinClift> k, lets get this rolling
15:03:17 <JustinClift> #topic "How are the docs for 3.5.0 looking?"
15:03:33 <JustinClift> Anyone here that's been on top of it?
15:03:42 <JustinClift> ndevos: ?
15:04:06 <JustinClift> That should prob be 3.5.1
15:04:14 <johnmark> ping
15:04:16 <ndevos> JustinClift: I think jdarcy was going to poke at some of the feature submitters
15:04:45 <hagarth> yes, documents are slotted for 3.5.1
15:04:55 <ndevos> more patches with docs got submitted, but I dont think its complete yet
15:05:19 <hagarth> an early version of the upgrade guide to 3.5.0 is now available at http://www.gluster.org/community/documentation/index.php/Upgrade_to_3.5
15:05:20 <glusterbot> Title: Upgrade to 3.5 - GlusterDocumentation (at www.gluster.org)
15:05:20 <JustinClift> k.  We should probably get someone to check out what's still outstanding
15:05:36 <hagarth> the upgrade page needs a lot more refining
15:06:12 <JustinClift> hagarth: Do we have a resource(s) who can get that finished in time for 3.5.1?
15:06:37 <hagarth> JustinClift: that does not involve a lot of work. We can get it done before 3.5.1.
15:06:57 <JustinClift> s/can/will/ ;)
15:06:59 <JustinClift> k
15:07:14 <JustinClift> #note an early version of the upgrade guide to 3.5.0 is now available at http://www.gluster.org/community/documentation/index.php/Upgrade_to_3.5
15:07:15 <glusterbot> Title: Upgrade to 3.5 - GlusterDocumentation (at www.gluster.org)
15:07:18 * dbruhn here
15:07:25 <JustinClift> k, moving on
15:07:38 <JustinClift> #topic "kkeithley to discuss the EL5 signing key"
15:07:45 <JustinClift> Nothing there, moving on
15:07:56 <JustinClift> #topic 3.5.1
15:08:12 <JustinClift> Do we have a tentative schedule or date we're aiming for?
15:08:49 <JustinClift> ... ?
15:08:50 <hagarth> ndevos: we probably should aim for a date
15:08:55 <hagarth> for 3.5.1
15:09:23 <ndevos> hagarth: 2 months after 3.5.0 was released?
15:09:45 <hagarth> ndevos: that sounds distant, we would need one earlier
15:09:54 <kmai007> hagarth: from 2 days before people have been reporting that glusterfs3.5.0 restarts itself after the update....
15:10:13 <kmai007> i have not verified this, but I recall JoeJulian did
15:10:16 <hagarth> given that there have been some issues reported with 3.5.0
15:10:23 <ndevos> hagarth: earlier is fine with me too :)
15:10:33 <JustinClift> 3 weeks from now?
15:10:41 <JustinClift> Or even 2?
15:10:48 <hagarth> 2 weeks sounds good to me
15:10:51 <ndevos> want a beta release first?
15:10:53 <JustinClift> (depending on docs, realistically)
15:10:57 <hagarth> we can have frequent minor releases
15:10:58 <JustinClift> If we can manage it, yeah
15:11:18 <JustinClift> Anyone object to 2 weeks?
15:11:25 <hagarth> kmai007: was this reported on gluster-users?
15:11:34 <kmai007> it was said in #gluster
15:11:40 <kkeithley> maybe we want to think about a 3.4.4 too, e.g. with the Ubuntu code audit fixes, once those get in?
15:11:54 <johnmark> kkeithley: +1
15:12:01 <kkeithley> Or are we done with 3.4.x?
15:12:02 <hagarth> kmai007: oh ok, will check with JoeJulian on that one.
15:12:03 <JustinClift> kkeithley: Good idea
15:12:11 <hagarth> kkeithley: +1 for 3.4.4
15:12:13 <JustinClift> kkeithley: If it's not a lot of effort, we should do it
15:12:32 <kkeithley> there's a patch up for review in gerritt.
15:12:35 <ndevos> 2 weeks for 3.5.1 sounds okay with me, or at least before the end of the 2nd week
15:12:52 <JustinClift> That lets ppl who want to keep on 3.4.x do so for a while, until more 3.5.x is in the wild
15:13:02 <hagarth> ndevos: cool!
15:13:10 <JustinClift> So, 2 weeks from now is abt 14th May
15:13:58 <JustinClift> #agree 2.5.1 tentative release date is 14th May
15:14:03 <ndevos> yeah, I should have some time next week to try and merge patches :)
15:14:04 <JustinClift> Hmmm, I hope that's the right command
15:14:23 <JustinClift> #agree 3.4.4 is a good idea
15:14:32 <JustinClift> kkeithley: Any idea when would be feasible date for 3.4.4?
15:14:38 <JustinClift> Aim for same day as 3.5.1?
15:14:42 <kkeithley> sure
15:14:47 <JustinClift> Cool
15:14:59 <JustinClift> ugh typo in #agree
15:15:01 <kmai007> hagarth: are there release notes for 3.5.0 now, online?
15:15:16 <kkeithley> we're talking about an alpha or beta for 3.4.4 and 3.5.1, right?
15:15:22 <JustinClift> kmai007: In tree view of git source repo
15:15:33 <kmai007> thanks JustinClift
15:15:53 <JustinClift> kkeithley: beta prefered of those two options
15:15:57 * JustinClift would like actual release
15:16:11 <JustinClift> But heck, it's a "we're aiming for it" date
15:16:23 <JustinClift> And when do things ever go to plan? :D
15:16:34 <JustinClift> #agree 3.4.4 tentative date for 14th May as well
15:16:40 <JustinClift> Moving on...
15:16:41 <kkeithley> I flat out won't do a GA without some kind of alpha or beta.
15:16:57 <JustinClift> kkeithley: No worries there.  Get one out a few days before then. :)
15:17:14 <JustinClift> #topic 3.6
15:17:36 <JustinClift> ... ?
15:17:38 <hagarth> okay, I added that one
15:18:05 <JustinClift> And ... ?
15:18:13 <hagarth> I have been pinged by a few folks to postpone the feature freeze date for 3.6 by a few days
15:18:27 <JustinClift> Solid reasons?
15:18:30 <hagarth> as of now, the feature freeze is planned for mid next week
15:18:46 <hagarth> yes, solid reasons.
15:18:57 <hagarth> I am wondering if we should move the schedule by a week or two
15:19:06 <JustinClift> When's the new proposed date?  Lets give them extra time.
15:19:06 <hagarth> to let features come by
15:19:23 <JustinClift> PPl have a lot to get done in near future.
15:19:36 <hagarth> I would propose a move of two weeks and set the feature free for 21st May
15:20:00 <JustinClift> Any objections?
15:20:30 <JustinClift> Doesn't sound there are any
15:20:33 <JustinClift> Sold!
15:20:37 <hagarth> yay!
15:20:51 <hagarth> I will take care of updating the Planning36 page on the wiki
15:21:03 <JustinClift> #action hagarth to update 3.6 planning page with new dates
15:21:10 <JustinClift> k, moving on...
15:21:24 <JustinClift> #topic Scaling CI/ Failing regression tests
15:21:39 <hagarth> I added that
15:21:53 <hagarth> we need regression tests to run seamlessly everywhere
15:22:00 <JustinClift> Completely agree
15:22:13 <hagarth> I think JustinClift's report is useful in figuring out which tests are problematic
15:23:00 * JustinClift hopes it helps figure out which ones to focus on, as it shows its not random tests
15:23:18 <hagarth> right
15:23:30 <hagarth> we also need to scale our jenkins infrastructure
15:23:30 <JustinClift> It would really, really help if the testing framework would catch stdout and stderr for each test, and direct it into a file
15:23:34 <kkeithley> do we have race conditions or timing issues in the tests? I ask because Justin says ~30 minutes to run 3.4 on rackspace, but my experience has been more like 80 minutes on the current machine.
15:24:03 <JustinClift> kkeithley: Ahh, that was from the "wall clock time" reported by the regression script itseslf
15:24:04 <hagarth> kkeithley: strange, 3.4 runs quite fast for me
15:24:06 <JustinClift> itself
15:24:19 <hagarth> kkeithley: fast as in 30 - 40 minutes
15:24:36 * JustinClift also points out the "1GB Performance" VM's in Rackspace are _not fast_
15:24:52 <hagarth> I think we need to follow up on the mailing list thread and take this to closure
15:25:06 <kkeithley> okay, not worth debating. I'd run a 3.4 regression to remind me, but there are 20 regressions backed up as it is
15:25:14 <hagarth> else scaling our jenkins infra would become very difficult
15:25:26 <hagarth> kkeithley: I meant running 3.4 tests on my laptop :)
15:25:44 <JustinClift> Anything modern is going to beat our VM's :)
15:26:03 <kkeithley> okay, I meant times on build.gluster.org
15:26:10 <JustinClift> #action hagarth to follow up Justin's Regression testing email on the mailing list
15:26:21 <JustinClift> k, moving on
15:26:39 <JustinClift> #topic "someone besides me (kkeithley) needs to pay attention to build.gluster.org regressions stalling/failing due to broken loopback devices, broken mounts, core files in /, etc  (just saying)"
15:27:02 <JustinClift> What are the signs that need to be watched out for?
15:27:03 * kkeithley just sayin'
15:27:09 <JustinClift> We can definitely automate the shit outta that
15:27:16 <JustinClift> just sayin'
15:27:18 <JustinClift> :)
15:27:56 <JustinClift> kkeithley: Let's discuss on gluster-infra or gluster-devel, and get it solved?
15:28:10 <hagarth> kkeithley: right, we should look at automating that.
15:28:20 <hagarth> and send an alert on to gluster-devel
15:28:31 <kkeithley> yup
15:28:45 <JustinClift> #action kkeithley to start email thread on gluster-devel about automating the checking for common regression host problems
15:28:52 <JustinClift> moving on...
15:29:03 <JustinClift> #topic comments on logging enhancements (raghug)
15:29:11 <JustinClift> raghug: Yours... :)
15:29:19 <raghug> Thanks justin
15:29:41 <raghug> you might be aware of enhancements to our logging infra to include msg-ids
15:29:50 <hagarth> yeah..
15:30:04 <JustinClift> Seen mention on mailing list, but haven't read the details yet
15:30:22 <raghug> basically msg-ids are used to identify standard error scenarios
15:30:43 <raghug> so, that users can refer to docs for reasons, remedial action etc
15:30:53 <JustinClift> Ahh, that sounds good
15:30:53 <raghug> the infra patch has gone in
15:31:13 <raghug> however, this discussion is related to usage of the infra
15:31:15 <JustinClift> Targeted for 3.6 yeah?
15:31:20 <raghug> JustinClift: yes
15:31:52 <raghug> the current approach is to tie the msg-id (a number) with msg (a string)
15:31:59 <hagarth> raghug: right
15:32:15 <raghug> however, as people pointed out in reviews, readability (for devs) is affected
15:32:43 <raghug> so, Nithya suggested to decouple msg-ids and mgs
15:32:47 <raghug> s/mgs/msgs
15:33:08 <raghug> there is a mailing thread on gluster-devel and users, with more details
15:33:12 <hagarth> raghug: what would the new proposal involve?
15:33:13 <JustinClift> That might make translations easier then (unsure)
15:33:31 <raghug> with the new proposal, we only define msg-ids
15:34:06 <raghug> devs are free to use any msg (ofcourse which makes sense with msg-id)
15:34:19 <raghug> basically we are not defining msg format for a msg-id
15:34:29 <hagarth> raghug: got it
15:34:35 <raghug> this way it wouldn't be too restrictive for devs
15:35:07 <hagarth> what would be the guidelines for using the same message id in different contexts?
15:35:08 <raghug> and enhances code-redability too, since entire msg is contained as an argument to gf_msg instead of being hidden behind a macro
15:35:52 <raghug> currently no guidelines have been thought of. Its left to judgement of devs and review process
15:35:58 <hagarth> if messages are semantically the same, do we use the same msg id?
15:36:02 <raghug> yes
15:36:03 <JustinClift> Hopefully the msg id for a particular error is the same, regardless of whether it gets exposed from CLI vs REST interface vs [whatever]
15:36:33 <hagarth> raghug: sounds like a neat and flexible model to me
15:36:35 <raghug> hagarth: thats the exact word, we don't define syntax of msg
15:36:41 <raghug> only semantics
15:36:58 <raghug> hagarth: yes, some of us felt that way too
15:37:09 * JustinClift isn't sure if the flexibility will lead to bad things (too many differnt approaches) or not.
15:37:13 <raghug> however, there are some arguments against this approach too
15:37:16 <JustinClift> Guess we get to find out :)
15:37:29 <hagarth> JustinClift: bad things should be caught in code reviews ;)
15:37:34 <raghug> I would request you guys to go through that mail thread and provide feedback
15:37:47 <raghug> hagarth: yes, code reviews are the way to go
15:37:54 <raghug> and probably a doc review too
15:37:54 <hagarth> raghug: will do
15:37:54 <JustinClift> I've worked on software which has msg-ids (unique across codebase), which all used same text-num format
15:38:04 <raghug> someone from doc-team
15:38:17 <JustinClift> Was really consistent for us on the project, and made tracking down the source of errors useful
15:38:30 <JustinClift> But yeah, this sounds useful
15:38:31 <JustinClift> :)
15:38:37 <raghug> JustinClift: please go through the mail on gluster-devel
15:38:44 <JustinClift> Good idea
15:38:47 <raghug> your feedback is appreciated
15:39:03 <raghug> so, that we can arrive at some consensus
15:39:28 <hagarth> raghug: sure, let us close this soon.
15:39:35 <raghug> hagarth: thanks
15:39:38 <JustinClift> #action JustinClift to read through the msg-igs proposal and provide feedback on gluster-devel
15:39:47 <JustinClift> gah typos today
15:39:57 <JustinClift> k, moving on...
15:40:09 <JustinClift> #topic Other items
15:40:23 <JustinClift> Anyone have something to raise?
15:40:36 <hagarth> lalatenduM_: any update on browsable admin guide?
15:40:42 <lalatenduM_> JustinClift, sorry for joining late
15:40:47 <JustinClift> ;)
15:40:56 <lalatenduM_> JustinClift, it is in progress
15:41:09 <lalatenduM_> JustinClift, as of now dont have much to report
15:41:18 <lalatenduM_> but we are working on it
15:41:43 <hagarth> lalatenduM_: ok
15:41:54 <JustinClift> np
15:42:04 <JustinClift> k, sounds like we're done then
15:42:11 <JustinClift> #endmeeting