15:02:45 <kshlm> #startmeeting Community meeting 2017-07-19
15:02:45 <zodbot> Meeting started Wed Jul 19 15:02:45 2017 UTC.  The chair is kshlm. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:45 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:45 <zodbot> The meeting name has been set to 'community_meeting_2017-07-19'
15:03:08 <kshlm> Waiting for 3 more minutes before continuing.
15:03:34 <kshlm> We have one topic of discussion on the meeting pad.
15:03:52 <amye> And we might not have the right people for that topic as well.
15:04:04 <amye> That's a ndevos question, yes?
15:04:18 * shyam just joined!
15:04:22 <amye> oh hai
15:04:24 <kshlm> Hey shyam!
15:04:33 <kshlm> ndevos, Yes.
15:04:34 * bulde too is here
15:04:36 <kshlm> And kkeithley too
15:04:40 <kshlm> Hey bulde
15:04:48 <kkeithley> well, ndevos (or I) do the builds, but the question is for the larger community.
15:04:50 <kshlm> Back to your old nick.
15:04:53 * jstrunk is here
15:05:00 <kkeithley> Is anyone really using el6 any more?
15:05:24 <kshlm> Wouldn't they be using it till it's supported?
15:06:10 * ndevos _o/
15:06:14 <kshlm> Let's start the topic officially now.
15:06:23 <kshlm> #topic Should we build 3.12 packages for old distros
15:06:25 <kkeithley> Or can we say if you're using el6, you get to stay on 3.10
15:06:57 <ndevos> I thought the plan was to drop el6 with 4.0?
15:07:19 <kkeithley> was it? okay then, question answered if that's the case
15:07:22 <vbellur> :O
15:07:23 <kshlm> kkeithley, Is there anything in particular that prevents us from building packages for el6?
15:07:30 <kkeithley> no
15:07:31 <ndevos> do we expect any problems with 3.12 on el6?
15:07:49 <ndevos> ok then :)
15:07:57 <bulde> i guess 4.0 is a good timeframe for dropping it, if everyone agrees
15:08:11 <kshlm> I'll also vote for dropping el6 and other old distros for 4.0.
15:08:40 <kshlm> For one GD2 most likely will not build with the golang versions in el6 AFAIK.
15:08:41 <ndevos> well, not everyone will agree, but if someone really wants el6 builds they can contribute their time for it
15:08:50 <kkeithley> there really aren't any "old" distributions that we're building pkgs for.
15:08:58 <kkeithley> Fedora drops off when koji won't do builds
15:09:40 <kkeithley> Ubuntu Xenial 16.04 LTS is the oldest Ubuntu, and yakkety and zesty will drop off when Launchpad won't do builds.
15:10:05 <kkeithley> Debian jessie and stretch are both still active. I guess we could ask the question about jessie
15:10:09 <Snowman> 16.04 LTS is last maintained stable afaik
15:10:23 <kkeithley> yeah, not suggesting dropping 16.04
15:10:32 <Snowman> thanks :)
15:10:44 <kshlm> CentOS 6 EOLs in Nov 2020.
15:11:00 <kshlm> There will be people using it till then I assume.
15:11:36 <Snowman> Jessie EOL is around April 2020
15:11:53 <ndevos> yes, people would like that, but we can make it clear that 3.12 is the last version we'll build in the CentOS Storage SIG for el6
15:11:55 <bulde> as ndevos mentioned, lets not stop doing it, but lets invite other contibutors
15:12:21 <kshlm> But what do we do if we can't even build required packages on el6.
15:12:35 <Snowman> its a nice idea
15:12:53 <kshlm> As I mentioned earlier, GD2 doesn't build on EL6,
15:13:25 <bulde> :O
15:13:32 <kshlm> Should we just try to keep the client bits buildable on EL6?
15:13:32 <vbellur> kshlm: nothing on epel would help building GD2 on el6 either?
15:13:46 <kshlm> vbellur, Nothing that is available right now.
15:14:25 <kshlm> Since GD2 is built with Go, we could technically just build the binary else where and ship the binary on EL6.
15:14:33 <vbellur> kshlm: right
15:14:54 <kshlm> But I guess that wouldn't be possible with the Storage-SIG and other build systems.
15:15:26 <ndevos> it depends, maybe we need to package some golang extension, but that might be doable
15:16:08 <kshlm> ndevos, It's not about golang packages. It's the golang compiler available on the platforms.
15:16:39 <kshlm> We need go1.8 to build GD2.
15:16:40 <ndevos> kshlm: right, and by the time Gluster 4.0 is ready, those might be available
15:16:52 <kshlm> IIRC, EL6 has go1.6 available right now.
15:17:11 <kshlm> ndevos, I hope so.
15:17:28 <ndevos> its not something I would worry about now, we just dont plan to build Gluster 4.0 on el6, and if someone wants to do it, we'll see what it takes
15:17:36 <kshlm> Cool.
15:17:52 <kshlm> So the current plan is not to worry about EL6 at all for 4.0.
15:18:05 <kkeithley> Once we drop el6 we can start using python3 too.
15:18:58 <ndevos> yeah, I think that should be acceptible
15:19:16 <bulde> yey!!
15:19:24 <kshlm> So does everyone present agree with this?
15:19:39 <ndevos> because 3.12 is a long-term-maintanance release, users should have sufficient time to move their storage servers to a more modern distro
15:19:44 <kshlm> EL6 support will be dropped with 4.0
15:20:10 * bulde agrees and we can extend 3.12 by another 3 months if its needed
15:20:12 <Snowman> sure sounds good
15:20:24 <bulde> ie, support to 3.12 branch
15:20:30 <vbellur> yeah, sounds good.
15:20:46 <kshlm> Sounds good to me too.
15:21:48 <kshlm> #agreed 4.0 will drop support for EL6 and other old distros. Will see what can be done if and when someone wants to do it anyway.
15:21:56 <kshlm> Okay.
15:22:04 <kshlm> We're done with the one topic.
15:22:22 <kshlm> If we have nothing else to discuss, I'll move on to the AI's.
15:23:42 <shyam> I would like to ask is 4.0 LTM or STM? coming right after 3.12 which is an LTM
15:24:04 <kshlm> #topic Is 4.0 LTM or STM?
15:24:11 <shyam> 4.0 is even hence LTM, 4.0 is after a LTM hence STM, which is true? :)
15:24:25 <kshlm> I'd like to keep 4.0 a STM.
15:24:43 <kshlm> We are sure to have lots of breakages with it.
15:24:52 <kshlm> And I wouldn't want to keep supporting it for long.
15:24:57 <amye> That's going to confuse people. The first release in a new cycle is going to be very exciting.
15:25:07 <nigelb> +1 for it being an STM.
15:25:10 <shyam> I agree, but that changes the mental pattern on odd/even being STM/LTM in 3.x line, so should we go with 4.0 and 4.1 as STM?
15:25:20 <nigelb> It's exciting, but don't use it in production (yet).
15:25:29 <shyam> and hence catch back on odd/even from 4.2?
15:25:59 <kshlm> I like this.
15:26:18 <Snowman> +1 STM (there can be some problems in upgrading to 4 from any version of 3 and everyone will be exciteded as amye mentioned) i vote for STM
15:27:09 <shyam> ok, 4.0 is an STM (I agree as well), considering the newness of a lot of features there. That I would say is settled in this conversation.
15:27:17 <shyam> What about 4.1 and the odd/even change?
15:27:31 <vbellur> we can skip 4.1 and jump to 4.2
15:27:42 <amye> It'll be very exciting, don't use it in production yet, but come tell us where the bugs are. Use 4.2 in production instead?
15:27:45 <shyam> That is a possibility as well, or call 4.1 an STM again
15:28:04 <nigelb> amye: Yep, that.
15:28:13 <jstrunk> How about skipping 4.0 start w/ 4.1?
15:28:32 <ndevos> heh, yeah, I wanted to propose that as well :)
15:28:47 <amye> Unfortunately, starting with 4.1 will also confuse everyone.
15:29:19 <amye> The question will be 'wait, did I miss a memo, where's 4.0'
15:29:29 <ndevos> do we need two STM's after each other, are we so sure that the code is bad to not mark 4.1 LTM?
15:30:13 <shyam> No, the question is if 4.1 is LTM, then in the 4.x line all LTMs are odd, which is different in the 3.x line, so should we retain odd/even or should we not?
15:30:17 <ndevos> I dont think we ever mentions LTM=even, STM=odd, its the first time I hear about that
15:30:18 <Snowman> i suggest not to drop 4.0 - https://www.gluster.org/community/release-schedule/
15:30:27 <Snowman> roadmap already has written 4.0 in it
15:30:33 <amye> Snowman, agreed. Everyone will be confused.
15:30:38 <nigelb> I agree with ndevos.
15:30:51 <nigelb> We can go with alternating releases are LTM/STM without committing to even/odd.
15:31:04 <amye> +1 on alternating
15:31:05 <shyam> ndevos: we do not, like I said "mental pattern" if that is not a problem, we have no worries
15:31:19 <ndevos> yeah, "Gluster 4.0" has been announced for a loooong time, renaming that to 4.1 is probably confusing for people that were looking forward to the release
15:31:50 <amye> Said another way, I will be confused if we drop it :P
15:31:53 <kkeithley> yeah, don't skip 4.0, that's my vote
15:32:10 <nigelb> Can we commit to reducing features going into 4.1 *now* before all of this, so we have time to fix bugs?
15:32:11 <ndevos> shyam: not sure who makes the mental association, now I learned there is at least one person doing it :)
15:32:31 <kkeithley> If you want to make 4.0 (and 4.1) STM, I'm okay with that. Then 4.2 is LTM.
15:33:26 <vbellur> even my vote is to have 4.0 and 4.1 STM.. move back to normal course from 4.2
15:33:27 * bulde too ok with 4.0/4.1 being STM and 4.2 being LTM
15:33:45 <bulde> and support 3.12 by 3 more months
15:33:58 <shyam> ^^^ +1
15:33:58 <kshlm> I vote for this too.
15:34:04 <ndevos> I would prefer 4.1 to be LTM, we have 3 months after 4.0 to make it stable enough for general usage
15:34:04 <jstrunk> sounds fine
15:34:07 <bulde> so people have 6 more months from moving from LTM to LTM
15:34:17 <Snowman> it will be more secure, some users will wait for 4.2 till bugs will be fixed
15:34:35 <Snowman> we should change "Planned LTM" asigned to 4.0 in roadmap
15:34:42 <amye> 4.1 should be LTM
15:35:25 <ndevos> I dont think it is perceived well if we say: hey, major release, but only deploy it after 6 months
15:35:26 <bulde> 4.1 should be LTM, because of the timeline, or the number?
15:35:42 <ndevos> timeline, 3 months after an stm
15:36:06 <bulde> should we do 4.1 after 45 days, and 4.2 after 3 month ?
15:36:20 <bulde> and call even number LTM
15:36:21 <amye> Nah, the 3 month release cycle is pretty set
15:36:25 <bulde> just a wild thought
15:36:26 <ndevos> please, lets try to stick to the schedule
15:36:44 <amye> Releases are hard enough to manage without throwing wildcards in. ;)
15:36:51 <vbellur> why don't we take a call about 4.1 being STM or LTM after 4.0 is out?
15:37:00 <ndevos> there will be 4.0.1 after 4 weeks, just like with any release
15:37:03 <amye> vbellur, ack. We do need to get 4.0 out.
15:37:09 <vbellur> we can decide based on the stability of 4.0
15:37:12 * bulde ack
15:37:29 <kshlm> Sounds good to me.
15:38:09 <ndevos> I prefer to give our users a little more stability on our release schedule, have it fixed, and no exceptions
15:38:32 <amye> I think we're all in favor of 4.0 STM, let's move on.
15:38:36 <shyam> ok, so 4.0 is an STM for sure. Rest comes in later!
15:38:40 <shyam> yup...
15:38:51 <Snowman> +1 @shyam
15:38:54 <kshlm> #agreed 4.0 is STM. Will take call on 4.1 and beyond later.
15:39:10 <kshlm> Thanks shyam.
15:39:19 <kshlm> Any other topics to be discussed?
15:39:20 <shyam> kshlm: add an action on me to edit web pages and milestones etc.
15:39:42 <shyam> or not ;) I will get that done anyway
15:39:57 <amye> shyam, shouldn't be hard. :)
15:39:59 <kshlm> #action shyam will edit release pages and milestones to reflect 4.0 is STM.
15:40:33 <kshlm> shyam, here you go.
15:41:10 * ndevos drops off in a minute or so
15:41:18 <kshlm> Once again, any more topics to discuss?
15:41:42 <kshlm> ndevos, You had an AI, do you want to discuss that?
15:42:13 <ndevos> kshlm: not really :) dont remember what it was, I probably didnt do it
15:42:42 <kshlm> ndevos, Okay. It was about Openstack and Gluster.
15:42:42 * ndevos adds a reminder to look at the meeting minutes tomorrow
15:42:55 <ndevos> ah, yeah, I plan to do that this week (again)
15:42:56 <Snowman> ndevos will check with Eric Harney about the Openstack Gluster efforts
15:43:05 <kshlm> Snowman, thanks :)
15:43:14 <Snowman> too late :)
15:43:18 <Snowman> no problem
15:43:20 <kshlm> ndevos, I'll keep it open.
15:43:30 <kshlm> nigelb, Thanks for you updates on your AIs.
15:43:32 <ndevos> yes please
15:44:05 <kshlm> That leaves 3 more AIs.
15:44:17 <kshlm> JoeJulian isn't here today, so skipping his AI.
15:44:51 <kshlm> The other 2 were related to the application specific test cases that we discussed last week.
15:45:16 <amye> s/last/previously
15:45:29 <amye> </helping>
15:45:30 <nigelb> kshlm: I'd updated at the last meeting, but forgot to update the notes.
15:45:56 <kshlm> amye, Still cannot forget the habit.
15:46:07 <amye> Oh, same here. :)
15:46:21 <kshlm> nigelb, Glad you did it this time.
15:46:56 <kshlm> Okay, so I completed my AI to reach out to vbellur and shyam to find out who was leading this testing effort.
15:47:04 <kshlm> The outcome was unclear.
15:47:43 <kshlm> And the other AI remained undone as a result.
15:48:05 <shyam> kshlm: The intention to test workloads, rather than point xlator based tests was strong, where it fits (glusto, gbench (more performance at present), other) and who writes/automates all this is possibly not yet clear, my 2 c's
15:48:44 <kshlm> shyam, Thanks.
15:49:05 <kshlm> Most (all) of us here understand the intention behind the tests.
15:49:22 <kshlm> But we needed someone to drive the intiative.
15:49:51 <kshlm> The question of who was leading the effort arose becuase no one present at the last meeting knew who put in the topic.
15:50:05 <nigelb> I think it was bulde?
15:50:14 <bulde> :O
15:50:21 <bulde> nigelb, for testing?
15:50:37 <bulde> i started some email threads... happy to help
15:50:38 <nigelb> I remember some conversation about adding the topic and not being able to talk about it.
15:50:45 <kshlm> The topic was 'Test cases contribution from community'
15:50:48 * shyam hums... "who took the cookie from the cookie jar..."
15:50:48 <nigelb> (no, I'm not saying you should lead it)
15:50:58 <kshlm> Anyone remember putting this down in the pad?
15:51:09 <amye> My kingdom for revisions.
15:51:19 <kshlm> It had been carried forward for a while.
15:51:23 <bulde> yes, i wanted to have more test cases which are application driven
15:51:54 <bulde> so community can write test cases which covers their usecases, so we make sure our commits doesn't break any of their usecases
15:52:12 <kshlm> bulde, So it was you then.
15:52:47 <kshlm> You intend to invite the community to write these tests.
15:52:49 * bulde clarifies who is me (amarts@redhat.com)
15:52:55 <kshlm> ?
15:53:04 <bulde> after we write the initial one
15:53:13 <kshlm> Okay.
15:53:29 <kshlm> Last time, we went along a slightly different track on this topic.
15:54:12 <kshlm> We started disucssing identifying the applications that are being used with gluster, to create test cases based on them.
15:54:31 <kshlm> And wanted to start a survey on the mailing lists to being identification.
15:54:57 <kshlm> bulde, Do you think we still need to do this?
15:55:09 <nigelb> So, I'm guessing this is building on the topic I've been talking about in terms of how we should test based on real-life use-cases and not break them?
15:55:18 <kshlm> nigelb, Yep.
15:55:19 <shyam> nigelb: ack
15:55:31 <bulde> nigelb, thanks for pitching in
15:55:51 * bulde 's head is processing sound from another meeting
15:56:13 <bulde> we would like to hear the major apps we should not break, and then use them in testing
15:56:37 <kshlm> bulde, That's basically what we arrived at last meeting.
15:56:51 <shyam> I would say we ask that question, once we get into a place of being able to execute on the promise, further the community survey coming up maybe a good place for it as well
15:56:51 <nigelb> So you're saying things like, "we're using gluster as the backend for storing elastic search index"?
15:56:59 <kshlm> So who's going to ask that question.
15:57:08 <nigelb> And we need to ensure their experience is not broken over time.
15:57:27 <bulde> if I have to ask it, I need at least 10days more
15:57:47 <nigelb> I think you can take time, because our testing situation needs to improve vastly before we can apply this.
15:57:52 <nigelb> And I'm happy to help as well.
15:58:10 <bulde> surely need help in this
15:58:22 <nigelb> I was planning on a survey to figure out the use-cases we want to commit to not breaking (before we go into specific applications)
15:58:34 * shyam drops off
15:58:38 <bulde> ok then I can take initiative to send mail.. but in general for most of the mails i send I haven't heard much back
15:58:39 <bulde> :-)
15:59:00 <kshlm> bulde, nigelb, Thanks for your inputs into this.
15:59:08 <amye> bulde++
15:59:37 <kshlm> I'm okay if this takes some time to reach completion.
16:00:04 <kshlm> I'll leave this AI open on you guys to take it forward as you see fit.
16:00:21 <kshlm> That's all the AIs we had.
16:00:34 <kshlm> And we're right on time to end.
16:00:41 <amye> thank you kshlm
16:00:45 <kshlm> If there's nothing else to discuss I'll end the meeting.
16:00:48 <nigelb> (I think this is a long-term project that I'm happy to fold into the "good builds conversation" and take ownership.)
16:00:58 <bulde> kshlm++
16:01:24 <kshlm> bulde, Thanks. FYI karma doesn't work in #gluster-meeting.
16:01:25 <Snowman> kshlm!++
16:01:37 <kshlm> Thanks for coming in today everyone.
16:01:41 <Snowman> thank you all for such a great contrib (/hug RH ppl)
16:01:55 <kshlm> I'll post the meeting minutes to the mailing list tomorrow.
16:02:07 <kshlm> Snowman, Thanks for coming in and participating.
16:02:09 <kshlm> :)
16:02:12 <kshlm> #endmeeting