15:01:43 <amye> #startmeeting Gluster Community Meeting  - 11 April 2018
15:01:43 <zodbot> Meeting started Wed Apr 11 15:01:43 2018 UTC.  The chair is amye. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:43 <zodbot> The meeting name has been set to 'gluster_community_meeting_-_11_april_2018'
15:01:56 <amye> Awesome, welcome. Hi Joe!
15:02:24 <amye> We've got a pretty light topic list, pls edit https://bit.ly/gluster-community-meetings with your things. :)
15:02:42 <amye> I'll give it a few minutes to see if there's anything come up for discussion.
15:03:30 <joes_phone> Just got off vacation. I completely unplugged and didn't think about this industry at all.
15:03:55 <amye> Fruity drinks with cocktail umbrellas, got it.
15:03:56 <joes_phone> So I've got nothing.
15:04:24 <joes_phone> Even better. Reason soaked mountain trails.
15:04:46 <joes_phone> Lol
15:04:46 <amye> #topic  removal of old deb packages from repo. Why?
15:04:53 <joes_phone> *rain
15:05:08 <amye> kkeithley, I think that's yours, take it away.
15:05:21 <ivan_rossi> it is mine. i will comply
15:05:29 <kkeithley> huh? no, not mine
15:05:39 <amye> Oh, sorry!
15:05:49 <kkeithley> what is the issue?
15:06:24 <ivan_rossi> older deb packages e.g. 3.8 have been removed from apt repo.
15:06:55 <ivan_rossi> it is causing me some grief i can explain. I just wanted to know the reason why
15:07:02 <kkeithley> we were tight on space, but I did some housekeeping
15:08:28 <kkeithley> 3.8 repos are still there
15:08:34 <amye> what's the grief?
15:08:44 <ivan_rossi> I need to build some VMs using old version 3.8. If you still have the debs around somewhere i am willing to have them in my apt repo
15:10:01 <kkeithley> 3.8 repos are still there
15:10:16 <kkeithley> https://download.gluster.org/pub/gluster/glusterfs/3.8/3.8.15/
15:10:37 <kkeithley> earlier 3.8.14 and earlier are tarred up, but they're all still there
15:11:07 <ivan_rossi> i thougth the tars just had the SOURCE code
15:11:15 <kkeithley> 3.9, and 3.7 and earlier are tarred up in https://download.gluster.org/pub/gluster/glusterfs/old-releases/
15:11:31 <ivan_rossi> if the have debs inside i'm a happiy camper
15:11:43 <joes_phone> Are you referring to Launchpad?
15:12:03 <ivan_rossi> no download.gluster.org
15:12:13 <joes_phone> There are no Ubuntu debs at d.g.o
15:12:16 <kkeithley> Everything is in the tar file. All the .debs, etc.
15:12:31 <joes_phone> Ah
15:12:44 <kkeithley> I can untar them if that makes things easier
15:13:12 <ivan_rossi> not a problem I have my own apt repo. i will get the tar and do it myself
15:13:56 <ivan_rossi> BTW, if you need a debian mirror I may be able to provide it
15:14:31 <kkeithley> sure, send me the URL and I'll add it to the Debian README.txt files
15:15:05 <ivan_rossi> first let's populate it. let's get in touch and i can do it
15:15:15 <kkeithley> sounds good
15:15:17 <amye> Sounds like we're good on this one.
15:15:20 <amye> Ok to move on?
15:15:26 <ivan_rossi> fine by me
15:15:32 <amye> #topic - gluster option man/help command
15:15:42 <ivan_rossi> mine again
15:15:59 <amye> Carry on. :)
15:16:11 <ivan_rossi> is there a way to get a short description of the volume options?
15:16:24 <ivan_rossi> I know some of them are in the docs
15:16:57 <ivan_rossi> but having a two line description of an option meaning available grom gluster command woukld be great
15:17:49 <ivan_rossi> something like gluster v get (someopton)help
15:18:27 <ivan_rossi> I thought i stumbled on something similar in the past but not being able to find it out
15:18:37 <ivan_rossi> so i am probably confused
15:18:54 <shyam> Forward looking design/change in options is to reduce the large swath of options to a few, and provide better context for the same (in docs and possibly CLI as well)
15:19:17 <joes_phone> +1
15:19:49 * shyam looking for the right github issue where above request can be added
15:19:50 <ivan_rossi> joe are you plussing what? me or shyam?
15:20:20 <joes_phone> Thought I must say, I've always been impressed with the quality of "gluster volume set help"
15:20:48 <shyam> ok, not finding the right github issue, @amye can you add an AI on me to get back on where to post this request, thanks!
15:20:51 <joes_phone> Plussing shyam
15:21:28 <amye> #action Shyam to hunt through github for the correct issue
15:21:44 <amye> Anything else on this?
15:22:04 <shyam> Ok here goes, was hiding in GD2 issue list: https://github.com/gluster/glusterd2/issues/503
15:22:08 <amye> Oh, even better.
15:22:47 <ivan_rossi> Joe just solved my request.
15:23:04 <ivan_rossi> i can do grep
15:23:50 <joes_phone> \o/
15:23:54 <amye> Sounds like we're good on this one too.
15:24:06 <amye> Shyam, you're next.
15:24:10 <amye> #topic - Switching minor releases to once in 2 month updates, than minor releases every month (based on #bugs fixed), post initial 3-6 minor releases, thoughts/concerns? [Shyam]
15:24:36 <shyam> So, we now do a minor release (say 3.12.x) every month
15:25:38 <shyam> Say, after 4-6 such releases, the bugs count or critical nature, reduces, we would like to save packaging and release times, and release once in 2 months after the initial 4-6 minor releases
15:26:03 <shyam> We will release ASAP, or on schedule if there are critical bugs
15:26:20 <shyam> Thoughts?
15:27:18 * kkeithley likes the idea of monthly for the first three minor releases, then bimonthly there after
15:27:24 <kkeithley> bimonthly = 60 days
15:27:39 <joes_phone> Seems reasonable as long as it's communicated well. If there is a prescription that release schedules are slipping it can wide confidence.
15:27:39 <ivan_rossi> makes sense. but for LTS only, otherwise it will never trigger
15:27:48 <joes_phone> *perception
15:27:58 <shyam> ivan_rossi: ack!
15:28:03 <shyam> joes_phone: ack!
15:28:14 <joes_phone> Stupid autocorrect
15:29:13 <ivan_rossi> jou want a metric like sum(crit_level*bug) and release if you go over a certain threshold. but it is probably too formal.
15:29:13 <joes_phone> *erode
15:29:43 <amye> That's my only worry, 'what's a critical enough bug'
15:29:51 <shyam> ivan_rossi: True, that maybe too formal
15:29:58 <joes_phone> If put it right in the release notes. "Next release in 60 days unless..."
15:30:24 <kkeithley> CVE should be one such critical enough bug
15:30:25 <ivan_rossi> amye: ML can probaly give a hint ;)
15:30:40 <kkeithley> otherwise we have to use our best judgement
15:30:49 <joes_phone> It's like art. You know it when you see it.
15:30:56 <amye> That's what.. sure. :D
15:31:03 <shyam> bugs causing data loss/corruption, frequent cores would qualify, rest as kkeithley says would be based on judgement
15:31:12 <amye> CVE is a good enough measure.
15:31:23 <shyam> joes_phone: ack on calling it out in the release notes
15:31:29 <ivan_rossi> daemon advertising on wrong ports, regressions
15:31:31 <amye> I mostly just wanted to make sure we had this conversation first.
15:32:48 <kkeithley> easily reproducible cores usually become CVEs, if we don't address them promptly
15:33:08 <kkeithley> a.k.a. denial of service
15:34:03 <joes_phone> Theoretically, cores are also code execution paths.
15:34:05 <amye> Those are good enough answers, that works.
15:34:27 <shyam> Ok, so conceptually we agree (will take this to the lists as well), and as long as for some (sane) definition of critical nature of a bug we will release minor updates in shorter cycles (at least till we have automation of packaging and testing of the same in place, where the time saving does not kick  in as an argument anymore)
15:34:27 <amye> Shyam, I don't see any major issues with this, want to start a ML post on this?
15:34:30 <shyam> :)
15:34:32 <shyam> ack!
15:34:57 <kkeithley> also fyi & fwiw we get ABRT reports from Fedora. Mostly from CentOS systems lately.
15:35:01 <amye> ML for documenting the proposal ++
15:35:47 <amye> Anything else on this topic?
15:35:54 <kkeithley> And guess who the lucky person is that receives them.
15:36:19 <kkeithley> I do open BZs, when there's useful info in them.
15:38:36 <amye> Going once for any other topics..
15:40:33 <amye> Looks like we're good on this.
15:40:37 <amye> Meeting host for next time?
15:40:48 <amye> 25 April, same time
15:41:34 <joes-phone> I'll volunteer
15:41:54 <amye> Oh cool. Will put you down, Joe.
15:42:00 <joes-phone> I'm WFH that day anyway. Should make it easy.
15:42:05 <amye> And that's a wrap on today!
15:42:08 <amye> #endmeeting