gluster_community_meeting_2017-05-10
LOGS
15:00:50 <kshlm> #startmeeting Gluster Community Meeting 2017-05-10
15:00:50 <zodbot> Meeting started Wed May 10 15:00:50 2017 UTC.  The chair is kshlm. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:50 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:50 <zodbot> The meeting name has been set to 'gluster_community_meeting_2017-05-10'
15:01:04 <kshlm> Hey all!
15:01:24 <kshlm> I'll wait for 3 more minutes for people to filter in before continuing.
15:01:56 <jdarcy> Greetings from Facebook's Lexington office.  ;)
15:02:45 <kshlm> Hey jdarcy!
15:03:13 <kshlm> Already in office? Isn't it a bit early?
15:03:38 <jdarcy> It's 11am here.
15:03:58 <kshlm> Oh!
15:04:09 <kshlm> I thought you were on the west coast.
15:04:23 * rafi is here
15:04:26 <jdarcy> I was until this week.
15:04:30 * BatS9 is here
15:04:38 * sanoj here
15:05:15 <kshlm> Ah, bootcamp.
15:05:24 <kshlm> Okay. Let's start with a quick roll call
15:05:28 <kshlm> #topic Roll Call
15:06:00 * kshlm is here
15:06:05 * BatS9 is here
15:06:08 <JoeJulian> o/
15:06:11 * sanoj is here
15:06:37 * jdarcy o/
15:06:54 <kshlm> Welcome guys.
15:07:07 <kshlm> The meeting agenda is at https://bit.ly/gluster-community-meetings
15:07:40 * kkeithley is late
15:07:42 <kshlm> We have 6 topics, most of them posted by amarts, who isn't here.
15:08:44 <kshlm> - Github issues
15:08:45 <kshlm> - Coverity progress
15:08:50 <kshlm> - Good build
15:08:59 <kshlm> - Experimental features?
15:09:00 <kshlm> - External Monitoring of Gluster performance / metrics
15:09:02 <kshlm> - What is the status on getting gluster-block into Fedora?
15:09:05 <kshlm> What shall we start with?
15:09:15 * ndevos arrives as well
15:09:41 <jdarcy> Just take 'em in the order above?
15:10:00 <kshlm> Okay.
15:10:06 <kshlm> #topic Github issues
15:10:17 <kshlm> No additional information on this topic.
15:10:39 <jdarcy> A question was raised this morning: is an issue closed when the patch is merged to master, or at some other point (e.g. when backports are done)?
15:11:13 * amye is late
15:11:20 <JoeJulian> It also might have been about answering support questions in github issues.
15:11:27 <ndevos> it should be closed when a release is made, imho, and note what version contains the fixes/features
15:12:12 <jdarcy> Also, I noticed looking through the issues that we have some high-priority issues attached to 4.0 and lower-priority issues attached to 3.12.  Seems weird.
15:12:33 <amye> GitHub issues is likely about how we don't have enough issues in Github by maintainer, we can take it up next week at maintainers issues
15:12:43 <amye> but what jdarcy said ties into this
15:13:58 <jdarcy> Sounds like there's nothing to resolve for this item in this meeting.
15:14:40 <amye> I will ping Amar to make this more robust for next meeting.
15:15:11 <kshlm> Is what JoeJulian said also under consideration for the next meeting?
15:15:23 <kshlm> ie., support questions in GH issues.
15:16:16 <amye> I think we have time to add JoeJulian's comments.
15:16:41 <jdarcy> My personal opinion is that GH issues is the wrong place for *support*, but good for FAQ fodder.
15:17:10 <JoeJulian> My personal feeling on the subject is that I don't like it. It leaves a lot of cruft that will never get properly answered that will show up in google searches.
15:18:05 <jdarcy> Can we stop that from happening?  Is it kosher to delete issues?
15:18:26 <amye> Impersonally, I'm fine with getting as much data as we can and redirecting back into bugzilla or whatever is the kosher solution
15:18:26 <JoeJulian> Plus, a lot of the questions are the same over and over again - even stuff that's in the documentation. Most of the time it's about changing somebody's thought process.
15:18:31 <BatS9> I can agree GH being the wrong place for support but what is the right place?
15:18:39 <amye> Even if that's 'put it on the mailing list'
15:19:04 <amye> BatS9, I'm not sure that we have a 'right place' because it's really volunteer to answer these
15:19:45 <jdarcy> Right now it's kind of mailing list (which also shows up in Google IIRC) and bugzilla (which doesn't?)
15:20:05 <JoeJulian> And IRC which also shows up in google.
15:20:32 <jdarcy> If only we could set up robots.txt in all of these places.
15:20:55 <amye> However, we have space in our upcoming documentation structure for FAQs so this is probably a conversation for putting the FAQ back there and improving its google-fu
15:22:28 <JoeJulian> Maybe osas could come up with some sort of regular reward system for contributing to documentation? or does karma work?
15:23:10 <amye> Eh, longer conversation, let's move on to the next topic
15:23:26 <amye> We certainly could, but not to derail the everything
15:23:33 * JoeJulian thinks amyee doesn't want an action item. ;)
15:23:42 <kshlm> Okay. Let's move on.
15:23:51 <kshlm> #topic Coverity progress
15:23:53 <JoeJulian> Gah, 1 e, I know. Bouncy bus.
15:24:18 <amye> Not in that tone of voice, but I want to see what the new docs structure covers. Happy to take an AI as we get here. :)
15:24:28 <kshlm> We have reduced from 860+ to 800 in last one month.
15:24:37 <kshlm> That's an improvement.
15:24:51 <JoeJulian> +1
15:24:53 <kshlm> Anything else we can do to help here.
15:25:22 <kshlm> It's mostly been misc who's been doing this IIRC.
15:25:29 <jdarcy> If Coverity (ASAN, whatever) fixes were tagged as such, they'd get to the top of my review queue.
15:26:02 <jdarcy> They're usually very easy to check.  Low-hanging fruit for people who want to keep the overall queue shorter.
15:26:21 <ndevos> jdarcy: maybe https://review.gluster.org/#/q/status:open+project:glusterfs+branch:master+topic:bug-789278 ?
15:26:27 <kshlm> They all use the same bug.
15:27:03 <kshlm> ndevos, that's what I was thinking of.
15:27:27 <jdarcy> Excellent.  I'll keep that one open along with my other standing searches.
15:27:33 <jdarcy> Thanks Niels.
15:28:27 <kshlm> Anything more to add about coverity?
15:28:57 <jdarcy> It would be very nice if the people giving -1 on some of these would propose their own alternatives.
15:29:29 <kshlm> jdarcy, Agree.
15:30:30 * ndevos drops off and will read the minutes later
15:30:37 <kshlm> Let's move on to the next topic.
15:30:41 <kshlm> #topic Good build?
15:31:34 <kshlm> From the added notes, I'm guessing amar wanted to discuss about the tools available verify if our builds are good.
15:31:51 <kshlm> Some that he has noted,
15:32:14 <kshlm> Coverity, lcov, systemtap. mutrace, valgrind.
15:33:25 <kkeithley> clang compile, cppcheck
15:33:53 <kshlm> (it isn't really fun when the person who added the topic isn't around to discuss it, especially when there isn't much context)
15:33:58 <kkeithley> if you're really brave try compiling with Intel icc or AMD acc
15:34:16 <kshlm> kkeithley, Are they available on linux?
15:34:24 <kkeithley> yes, they are
15:34:56 <kshlm> Oh cool.
15:35:00 <kkeithley> (otherwise I wouldn't have mentioned them. ;-))
15:35:13 <kshlm> I thought icc was windows only.
15:35:14 <kkeithley> free non-commercial license
15:35:47 <kshlm> TIL.
15:35:51 <sanoj> sparse (used by linux kernel) could be another
15:36:12 <kshlm> sanoj, What does it do? (First time I'm hearing of it)
15:37:07 <sanoj> Has some set of semantic parsing checks.. dont recall exactly . but u need this for a patch to get merged upstream.
15:37:39 <kshlm> sanoj, okay. Thanks.
15:37:41 <sanoj> some things are like address space checks (user/kernel ) not relevant to us. but there may be othercheck relevant
15:38:27 <kshlm> I'll note it down. Maybe we can one day use it.
15:38:44 <kshlm> Shall I move on to the next topic?
15:38:55 <kkeithley> https://software.intel.com/en-us/articles/intel-c-compiler-170-for-linux-release-notes-for-intel-parallel-studio-xe-2017
15:39:35 <kshlm> Let's move on.
15:39:50 <kshlm> The next topic is experimental features.
15:40:01 <kshlm> It has no additional information, so I'm skipping it.
15:40:32 <kshlm> #topic External Monitoring of Gluster performance / metrics
15:40:51 <BatS9> Yes I'm not sure if this is the right forum for this topic / question
15:41:03 <BatS9> We are rather sensitive to responstimes therefor we like to monitor any abnormality in times. We are currently monitoring Glustermetrics by parsing profile info every 30 seconds and sending the data to an external trapper. It does its job but I was wondering if there Is a better solution available or planned for this kind of monitoring.
15:41:48 <vbellur> BatS9: what kind of abnormality are you interested in? performance or events that might happen in a cluster?
15:42:03 <BatS9> Purely performance in this case
15:42:45 <vbellur> BatS9: ok, this is how most deployments monitor performance today. Do you have any other alternatives in mind when you refer to a better solution?
15:43:35 <vbellur> it might be cool to have io-stats emit notifications when it notices latencies greater than some threshold
15:44:14 <JoeJulian> facebook talked about how they added their own stat dumps to text files on the servers to avoid rpc calls at the last gluster summit.
15:44:30 <vbellur> JoeJulian: most of that is in mainline now IIRC
15:44:35 <kshlm> Yeah. They dump to json IIRC.
15:44:52 <JoeJulian> +1
15:44:54 <kshlm> vbellur, Cool! When did that get in?
15:45:08 <BatS9> I don't really have my a plan in mind, more interested in how it should be done and if there was some more out of the box solution planned
15:45:23 <vbellur> kshlm: http://review.gluster.org/12210
15:46:41 <kshlm> That's pretty old! Why haven't we publicised this more?
15:47:01 <vbellur> BatS9: maybe you can check that feature out..
15:47:18 <JoeJulian> BatS9, imho that's out of scope. Once you have the data, then it's tools like graphana or kibana to tease out the information.
15:47:54 <JoeJulian> grafana
15:48:39 <vbellur> kshlm: probably got lost somewhere in the middle of everything that we do :)
15:49:08 <BatS9> JoeJulian: I ment more on the plan of getting the data
15:49:27 <BatS9> For example if it could be extracted via the API (Maybe this can be done today?)
15:49:38 <BatS9> The same data that is viewable in profile info that is
15:51:05 <kshlm> BatS9, The review/patch that vbellur linked to has another way to get the information you're looking for.
15:51:20 <BatS9> I'll have a look, thank you for the link vbellur
15:51:41 <kshlm> Cool.
15:52:00 <JoeJulian> I would use that FOP sampling to add the data to ELK and monitor that way. Should make things really obvious if something's wrong.
15:52:12 <kshlm> Checkout the tests/basic/fop-sampling.t file for an example of how to get to the information.
15:52:45 <JoeJulian> vbellur++ kshlm++
15:52:45 <zodbot> JoeJulian: Karma for vbellur changed to 1 (for the f25 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:52:48 <zodbot> JoeJulian: Karma for kshlm changed to 2 (for the f25 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:52:49 <kshlm> BatS9, If you're happy with the answers I'll move on to the next topics.
15:53:06 <BatS9> Yes I'm happy with the answer
15:53:12 <kshlm> Awesome
15:53:31 <kshlm> #topic What is the status on getting gluster-block into Fedora?
15:53:39 <kshlm> Anyone have any idea on this?
15:53:41 <kkeithley> Yeah,
15:53:43 <kshlm> kkeithley, ?
15:53:58 <kkeithley> I finally got an answer, but
15:54:19 <kkeithley> right now it's being built in COPR, which is fine as far as that goes
15:54:32 <kkeithley> But the better answer would have been to get it into Fedora
15:54:44 <kkeithley> and then we can put it in CentOS Storage SIG
15:55:41 <vbellur> kkeithley: I think Prasanna is looking for some help to navigate through the Fedora inclusion process
15:55:42 <kkeithley> building in COPR means someone has to put it on d.g.o. That doesn't scale too well
15:56:25 <kshlm> kkeithley, Why? Couldn't you just add the instructions on how to use COPR, like how its done for Ubuntu/PPAs?
15:56:53 <kshlm> Also, why do we need to wait to get into fedora to get it into the StoragSIG?
15:57:32 <kkeithley> Putting it in Fedora gets reviews of the .spec file, which is good (but maybe not strictly necessary) for the Storage SIG
15:57:44 <kkeithley> and also good for <cough>downstream</cough>
15:59:03 <kshlm> Sounds reasonable.
15:59:12 <kkeithley> anyway, that's all I wanted to say.
15:59:30 <kshlm> Okay. So no actual progress on getting it into Fedora then.
15:59:49 <kshlm> (we are almost outta time)
15:59:57 <kkeithley> The gist of Prasanna's reply was that he has no cycles to do that.
16:00:13 <kkeithley> which seems like an important thing (IMO) to budget time for.
16:00:51 <kshlm> kkeithley, Okay.
16:00:53 <kkeithley> also, before we run out of time, I sent a pull request for an update to the community packages page over a week ago
16:01:04 <kkeithley> but it still hasn't been pulled
16:01:10 <kkeithley> docs
16:01:14 <kshlm> ping amye maybe?
16:01:33 <kshlm> We have a last minute addition to the topics list.
16:01:39 <kshlm> vbellur, Was it you?
16:01:42 <JoeJulian> e
16:01:42 <JoeJulian> me
16:01:55 <kshlm> JoeJulian, Oh okay.
16:02:07 <kshlm> But we're out of time today.
16:02:13 <JoeJulian> Next time then
16:02:18 <kshlm> If you don't mind, we can take it up next week.
16:02:19 <JoeJulian> Hopefully we'll know more.
16:02:23 <kshlm> Cool.
16:02:30 <kshlm> Also,
16:02:51 <kshlm> I might not be available to host the next meeting on the 24th.
16:03:01 <JoeJulian> But just to ensure it's mentioned. GlusterFS support was removed from Openstack Ocata.
16:03:33 <kshlm> I'll notify in advance if an alternative meeting host is required.
16:03:48 <kshlm> JoeJulian, I'll add that to the meeting notes for the next meeting.
16:03:54 <JoeJulian> I'd volunteer but I'm guaranteed to be 5 min late.
16:04:04 <kshlm> Thanks for coming in today everyone.
16:04:09 <kshlm> See you all in 2 weeks.
16:04:13 <kshlm> #endmeeting