12:05:09 <jdarcy> #startmeeting
12:05:09 <zodbot> Meeting started Fri Apr 17 12:05:09 2015 UTC.  The chair is jdarcy. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:05:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
12:05:16 <jdarcy> First, has anybody been able to spend *any time at all* on 4.0 stuff?  Seems like 3.7 has pretty much eaten everyone alive.
12:05:40 <hagarth> largely that seems to have been the case
12:05:50 * krishnan_p has been doing only 3.7 related stuff all along.
12:06:02 <hagarth> I promise that I will write up the overlay xlator feature page by next wednesday!
12:06:30 <krishnan_p> hagarth, look forward to know what it's all about.
12:06:31 <jdarcy> hagarth: That would be awesome.  I think the container-convergence use case could be huge, and there are others as well.
12:06:55 <jdarcy> #action hagarth to write overlay-xlator feature page
12:07:44 <jdarcy> OK, so that leads into the next topic...
12:07:55 <jdarcy> #topic Kickoff activities
12:08:23 <jdarcy> I'm going to be in BLR a little over a week from today, then not long after that is Barcelona.
12:08:41 <jdarcy> Any thoughts on what our 4.0 agenda should be for either of those?
12:08:50 <hagarth> I think we need to firm up an agenda for BCN
12:08:54 <jdarcy> Also, who else will be in Barcelona?
12:09:18 * krishnan_p should be (assuming Visas are a breeze)
12:09:37 <hagarth> jdarcy: good number of Red Hat developers are going to be there. xavih will be there.
12:09:56 <hagarth> we are also looking at other interested folks to being there
12:10:24 <jdarcy> That will be good.  Maybe the BLR agenda should be to prepare materials etc. for the true kickoff in Barcelona.
12:10:37 <krishnan_p> For features that have feature pages and good roadmap of development activities, we could look for common infrastructure they need.
12:10:46 <hagarth> jdarcy: +1
12:11:15 <krishnan_p> For the rest that don't have concrete shape yet, we need to have some discussions/debates on technology choices etc. For e.g thousand-node-glusterd - golang, etcd and so on.
12:11:36 <krishnan_p> jdarcy, Agree.
12:11:58 <jdarcy> We have a five-hour slot on April 30 for discussing "post 3.7" stuff.
12:12:48 <hagarth> I am interested to see if all maintainers can present the spectrum of possibilities in their and related components for 4.0
12:12:51 <krishnan_p> jdarcy, Could you have an etherpad where features (owners) can 'bid' for slots for discussion?
12:12:56 <jdarcy> krishnan_p: Would it be worthwhile to structure part of the technology evaluation as a hands-on session?  Actually get on some machines together and poke at etcd, consul, etc.?
12:13:03 <hagarth> that way we would get a fair chunk of good ideas flowing.
12:13:07 <jdarcy> krishnan_p: Excellent idea.
12:13:27 <hagarth> krishnan_p: yes, that sounds good.
12:13:30 <krishnan_p> jdarcy, hands-on would be a great way to start.
12:13:36 <jdarcy> #action jdarcy to create Etherpad for scheduling BLR 4.0 discussion slots.
12:14:09 <krishnan_p> hagarth, Agree. It make sense to list the range of possibilities.
12:15:10 <jdarcy> Is there a big screen somewhere in the BLR office suitable for a group to view stuff together?
12:15:39 <krishnan_p> I think so. BLR office cafeteria has provision for that. hagarth ?
12:15:51 <jdarcy> ISTRC there are classrooms with projectors, which might (or might not) be available.
12:16:07 <hagarth> krishnan_p: yes that or one of the larger conference rooms might do
12:16:56 <krishnan_p> Are there other features that would like to evaluate technologies during the 5-hour sprint on Apr 30th?
12:17:44 <jdarcy> I don't know if it would be hands-on, but I'd like to get a handle on which database technology to use in various places.
12:18:07 <krishnan_p> I was thinking if we could have VM images (or containers), with all the s/w, that we could use for testing ideas.
12:18:22 <jdarcy> SQLite is making people sad, and in any case we should try to converge on one instead of multiple (index and changelog are very DB-like too).
12:18:33 <krishnan_p> 5 hours would be too less to struggle with installation issues.
12:18:42 <jdarcy> Also, NSR journals and stat/xattr cache.
12:19:06 <hagarth> yeah, we need to look at consolidating all of these.
12:19:33 <krishnan_p> jdarcy, I could add the list of technologies to the etherpad you would be creating for slots and work on getting a common VM image with all technologies that we seem to test.
12:19:53 <hagarth> I think a column DB would be cool .. having a gfid as the row and each xlator as a column might be something viable
12:20:07 <krishnan_p> If I may be so bold, I would suggest we discuss volgen ...
12:20:14 <jdarcy> #action TBD to create VMs/containers for evaluating base technologies
12:20:34 <jdarcy> krishnan_p: I totally agree with you.  That needs to be burned to the ground and done over.
12:20:36 <hagarth> krishnan_p: the yaml way to do volgen? ;)
12:21:02 <krishnan_p> jdarcy, hagarth I am already booking a slot for volgen once the etherpad is ready :)
12:21:09 <jdarcy> It's going to be hard, but adding new stuff there without introducing bugs is becoming *impossible*.
12:21:20 <krishnan_p> hagarth, I haven't really thought about it in recent times. Yaml seems to be in the vogue recently
12:21:41 <jdarcy> Should that be considered part of the glusterd effort we already have, or separate?
12:21:43 <krishnan_p> jdarcy, I am interested in it purely from the point of view of expressibility and maintainability
12:21:49 <hagarth> krishnan_p: we need to simplify & dumb it down for all of us to easily add/generate translators.
12:22:09 <krishnan_p> jdarcy, separate. Anything related to glusterd is either all in or none at all.
12:22:34 <krishnan_p> jdarcy, ... so far. I think we should break things down into smaller features.
12:22:48 <jdarcy> One thought I already have is that we should split volfile generation into two parts - a "core" part when changes are made, and a "polish" stage done on demand by the secondary users (NFS, shd, snapshot, etc.)
12:23:14 <jdarcy> More of a filter on the core rather than copying/pasting code to generate a whole new volfile.
12:23:21 <krishnan_p> jdarcy, we should throw all these ideas on volgen there, like hagarth suggested earlier
12:23:32 <jdarcy> I'll create a feature page for it.
12:23:42 <krishnan_p> jdarcy, thanks a ton.
12:23:45 <jdarcy> #action jdarcy to create feature page for volgen refactor/rewrite
12:24:15 <krishnan_p> jdarcy, so who is the VM/containers action item on? I could take it up if no one is.
12:24:34 <jdarcy> krishnan_p: I suspect primarily you, but others (e.g. myself) might help.
12:24:57 <krishnan_p> jdarcy, sure.
12:25:17 <jdarcy> #topic New features
12:25:31 <jdarcy> Any other ideas for things we should add, or rip out and replace?
12:25:40 <jdarcy> (like we don't have enough already)
12:26:53 <jdarcy> I'll take that as a "no"  ;)
12:27:02 <hagarth> jdarcy: don't think we have feature pages for things like compression at rest, dedup etc.
12:27:11 <hagarth> but these are add ons
12:27:19 <hagarth> not something that we are ripping out and replacing
12:27:34 <jdarcy> hagarth: OK.
12:28:12 <krishnan_p> I think we should use the Apr 30th meeting and BCN to seriously identify all the infrastructure changes that no feature page would explicitly mention
12:28:22 <jdarcy> #action jdarcy to add (skeleton) feature pages for compression/dedup
12:28:30 <krishnan_p> we don't want many implementations of the same thing right at the beginning of 4.0 :-)
12:28:42 <jdarcy> krishnan_p: +1
12:28:52 <hagarth> krishnan_p: +1
12:29:22 <krishnan_p> jdarcy, you have mentioned polar SSL and msgpack etc. to replace older technologies earlier.
12:29:39 <hagarth> we also would need to figure out details like the branching strategy, upgrade paths for existing deployments etc.
12:29:46 <krishnan_p> jdarcy, do these qualify as the invisible features that we should test their merit and relevance for 4.0?
12:30:12 <jdarcy> krishnan_p: Indeed.  Perhaps the fact that I'm afraid to touch the RPC code at this point is a sign that it should be on the "hit list".  ;)
12:30:29 <krishnan_p> hagarth, ah, that too! The really difficult, yet important to discuss early on. +1
12:30:52 <jdarcy> #action jdarcy to add feature page for RPC changes
12:30:57 <krishnan_p> jdarcy, and since I touch it more often than I should be allowed to :)
12:31:28 <jdarcy> hagarth: Should that be on the etherpad, or maybe a separate thing?
12:32:06 <hagarth> jdarcy: maybe somewhere in the agenda for BCN?
12:32:35 <jdarcy> hagarth: Absolutely.  I'm sure the other people on April 30 won't let it go undiscussed either.
12:32:48 <krishnan_p> hagarth, definitely for BCN.
12:32:52 <hagarth> jdarcy: right
12:33:22 <hagarth> I would like to add native object store & block interfaces for 4.0 too
12:33:28 <jdarcy> When you say BCN it always makes me think of WBCN - a Boston rock-oriented radio station.
12:33:29 <hagarth> (as new features)
12:33:42 <hagarth> jdarcy: haha, I am too lazy to type out barcelona frequently
12:33:58 <jdarcy> #action hagarth to add feature pages for native object/block
12:34:01 <jdarcy> :-P
12:34:06 <hagarth> jdarcy: thanks :D
12:34:38 <jdarcy> #topic Open floor
12:34:43 <jdarcy> Anything else we need to discuss?
12:35:00 <krishnan_p> Language choice(s) for 4.0 development.
12:35:11 <jdarcy> I was thinking of Lua.
12:35:12 <krishnan_p> Yeah, I opened the can of worms.
12:35:40 <krishnan_p> jdarcy, didn't expect that. Why Lua?
12:35:59 <jdarcy> Just kidding.  If I were more evil, I'd suggest Java or Javascript.
12:36:03 <krishnan_p> I have no repartee for "why not?" anyways :)
12:36:08 <hagarth> jdarcy: node.js passed my mind ;)
12:36:53 <krishnan_p> jdarcy, I was wondering if we are open to possibility of using golang for some parts of glusterd. Like volgen, code managing entities like shares/volumes/bricks/tenants etc
12:36:58 <jdarcy> I think we're stuck with a lot of C code for quite some time, so ease of both calling in to C and calling out from C will be necessary except for completely rewritten separate daemons.
12:37:27 <hagarth> right
12:37:28 <krishnan_p> jdarcy, Agree.
12:37:53 <krishnan_p> jdarcy, what about a feature page on your code-generation tooling for glusterfs
12:38:10 <jdarcy> I think we can also say that Python is "already in" due to its use in georep, Swift, etc.
12:38:42 <hagarth> the native object server can be in a cool language :)
12:38:45 <jdarcy> #jdarcy to create feature page(s) for new languages and/or code generation
12:39:07 <hagarth> that will also give us opportunities to create gfapi bindings in various languages :D
12:39:24 <jdarcy> hagarth: Right.  With a decent foreign-function interface, things that only need to call *in* to the C core are easier.  Though, watch out for callbacks.
12:39:42 <hagarth> jdarcy: true
12:40:14 <krishnan_p> In the spirit of open floor, the next item would be memory management, given that we are stuck with C
12:40:28 <jdarcy> I think golang makes that pretty easy.  Lua's pretty good.  Java's worse, Ruby and Javascript worse still.
12:40:55 <krishnan_p> I was wondering if we could make all objects in glusterfs use kref like embedded objects to do unified management.
12:40:56 <jdarcy> krishnan_p: You didn't just bring a can of worms.  You brought a whole six-pack, didn't you?
12:41:04 * krishnan_p ducks :)
12:41:35 <JustinCl1ft> Is there a language which would let us look at a full dump of the "GlusterFS has grown to 18GB RAM" scenario, and be able to tell the source of the excessive usage?
12:41:57 <jdarcy> Another alternative might be one of the C garbage collectors.  Is Boehm/Diemers still current?
12:42:05 <hagarth> JustinCl1ft: gluster statedump + some scripts
12:42:37 <jdarcy> https://github.com/ivmai/bdwgc/
12:42:44 <JustinCl1ft> hagarth: Cool.  We don't seem to do it currently, but it's something we probably should.  Doesn't sound like a 4.0 thing then, but more of a current gen possibility.
12:43:18 <krishnan_p> JustinCl1ft, we should improve our observability as a system, oh I mean't distributed system.
12:43:21 <hagarth> I think windows/MS do use it currently
12:43:38 <hagarth> krishnan_p: +1
12:44:03 <jdarcy> hagarth: You think Windows etc. use BDW?  Didn't know that.
12:44:25 <krishnan_p> I would like to add a few my (provocative) thoughts to a section on memory management in the etherpad.
12:44:26 <hagarth> jdarcy: remember reading that windows, .net et al were using it.
12:44:40 <jdarcy> JustinCl1ft: I almost proposed a LISA talk on everything GlusterFS got wrong from an ops perspective.  Lack of observability was a big one.
12:45:02 <krishnan_p> I tried URCU for a similar purpose (existence guarantees and not Performance)
12:45:42 <JustinCl1ft> jdarcy: That'd be a good talk for other people to learn from, and for our 4.0 planning
12:46:00 <jdarcy> I suggest that we should let memory-management ideas "incubate" a bit longer.  Maybe a gluster-devel email thread?
12:46:01 <krishnan_p> jdarcy, you could give us all a preview of the talk
12:46:09 <krishnan_p> jdarcy, sure.
12:46:21 <hagarth> sounds good
12:46:26 <jdarcy> #action krishnan_p to start email thread about memory-management strategies
12:46:57 <jdarcy> #action jdarcy to create "How GlusterFS failed ops" presentation (possibly for LISA)
12:47:08 <jdarcy> BTW, I encourage others to propose talks for LISA too.  Great conference.
12:48:17 <hagarth> jdarcy: cool, thanks for the pointer.
12:48:18 * krishnan_p needs to gather a lot of courage to propose a talk for LISA.
12:48:22 <jdarcy> CFP was just extended for a few days.  https://www.usenix.org/conference/lisa15/call-for-participation
12:49:33 <jdarcy> Anything else?  Going once...
12:49:48 <krishnan_p> None from me.
12:50:04 * JustinCl1ft shakes head
12:50:05 <hagarth> nothing more from me, fyi - awaiting invite letter for visa filing .. so BCN is still on shaky grounds for me ;)
12:50:27 <jdarcy> I'm sure it'll work out.
12:50:41 <jdarcy> ...and looks like we're done.  Thanks for a productive meeting, guys.
12:50:44 <jdarcy> #endmeeting