14:01:24 <hagarth> #startmeeting
14:01:25 <zodbot> Meeting started Wed Nov 27 14:01:24 2013 UTC.  The chair is hagarth. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:01:25 <glustermeetbot> Meeting started Wed Nov 27 14:08:03 2013 UTC.  The chair is hagarth. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:25 <glustermeetbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:01:29 <hagarth> hi all
14:01:46 <lpabon> hello
14:01:47 <hagarth> meeting agenda is at http://titanpad.com/gluster-community-meetings
14:02:14 <hagarth> #topic 3.5 release updates
14:02:40 <hagarth> so, here are the updates on 3.5
14:02:50 <hagarth> 1. release-3.5 has been branched
14:03:11 <hagarth> you can checkout release-3.5 in git now
14:03:22 <hagarth> 2. we will start with a regular stream of 3.5 qa releases
14:03:33 <johnmark> OH HAI
14:03:40 <johnmark> hagarth: thank you
14:03:46 <hagarth> 3. we had planned for a test day on nov 29th
14:04:03 <johnmark> hagarth: sweet re: 3.5
14:04:06 <hagarth> considering that it is the holiday week in US, I am inclined to push it out by a week
14:04:16 <hagarth> any thoughts on pushing the test day by a week?
14:04:24 <lalatenduM> #agree
14:04:25 <johnmark> hagarth: yes, definitely next week
14:04:44 <johnmark> hagarth: I assume 3.5 builds? and we can actually try stuff out?
14:04:56 <hagarth> johnmark: that will start from tomorrow
14:05:00 <purpleidea> will rpm's be built as usual?
14:05:12 <hagarth> purpleidea: yes, as with all qa releases rpms will be available
14:05:27 <hagarth> we also need to note that all features in core did not make it to 3.5
14:05:36 <hagarth> such features will get pushed out to 3.6
14:06:00 <johnmark> hagarth: cool
14:06:13 <johnmark> hagarth: we just need to list those out
14:06:20 * johnmark is tracking etherpad, adding notes
14:06:26 <hagarth> for features that made it to 3.5, we need to have test cases defined in the appropriate feature pages so that everybody can give it a spin
14:06:36 <hagarth> johnmark: right, I will take that AI on me
14:06:47 <johnmark> hagarth: so if we push the test day out by a week, then that will make it December 6
14:06:48 <hagarth> #action hagarth to update planning35 page
14:06:50 <johnmark> hagarth: thank you
14:06:55 <hagarth> johnmark: right
14:07:18 <hagarth> #action feature owners to update test plans in feature pages
14:07:39 <hagarth> we also need to evolve documentation for 3.5
14:07:56 <hagarth> i have this plan in mind, let me know if you have other thoughts on how we can reach there
14:08:10 <johnmark> hagarth: ok
14:08:21 <hagarth> we have standardized on markdown for writing our docs
14:08:24 <johnmark> hagarth: so feature owners need ot get on the ball if they want their features tested
14:08:33 <hagarth> johnmark: right
14:09:02 <hagarth> I think we need the entire admin-guide to be updated and made browseable
14:09:14 <johnmark> hagarth: +1
14:09:18 <lalatenduM> hagarth, #agree
14:09:21 <gkleiman> december 6 test day in what time zone?
14:09:26 <purpleidea> hagarth: as you may or may not know, i wrote docs (in markdown) for puppet-gluster. feel free to integrate them into gluster docs (if you want) and/or link to my DOCUMENTATION.md file.
14:09:36 <johnmark> #action jmw to add admin guide to gluster-docs-project repo
14:09:45 <johnmark> purpleidea: awesome :)
14:09:49 <hagarth> can we have one or more documentation marathons scheduled before 3.5? would there be enough interest?
14:10:06 <johnmark> hagarth: I think we need to try it, but we need the docs team to particiapte
14:10:13 <ndevos> where are the features documented? is there a page that shows the markdown documentation in a rendered form?
14:10:26 <hagarth> gkleiman: december 6 for 24 hours, hopefully the community can support all day
14:10:31 <johnmark> ndevos: those are two separate questions
14:10:40 <hagarth> ndevos: you can browse the markdown documentation in github
14:10:58 <ndevos> ah, github!
14:10:59 <johnmark> ndevos: this is the feature planning page: http://www.gluster.org/community/documentation/index.php/Planning35
14:11:03 <hagarth> ndevos: the features have minimal feature pages on gluster.org
14:11:07 <purpleidea> ndevos: pandoc can render to pdf, see https://github.com/purpleidea/puppet-gluster/blob/master/Makefile
14:11:19 <johnmark> purpleidea: ...and lots of other formats
14:11:20 <ndevos> johnmark: yes, but that is not markdown, or is it?
14:11:39 <hagarth> ndevos: github renders markdown
14:11:41 <lpabon> fyi, we use markdown doc in github also for gluster-swift
14:11:51 <johnmark> ndevos: nope. and that gest into the territory of our migration of ht eweb site to git, markdown, and flat files
14:11:58 <johnmark> ndevos: but that is a topic for another day
14:11:58 <purpleidea> ndevos johnmark : github markdown is similar to markdown but slightly different
14:12:19 <purpleidea> you can write markdown that is compatible with both.
14:12:22 <lpabon> ndevos: Example:  https://github.com/gluster/gluster-swift/blob/master/README.md
14:12:24 <johnmark> ndevos: but yes, we'll need to move the planning pages (and everythign else) to markdown shortly
14:12:29 <hagarth> i plan to add a documentation day as part of the 3.5 schedule, any objections to that?
14:12:37 <johnmark> hagarth: none. go for it
14:12:52 <hagarth> #action hagarth to add documentation day in 3.5 schedule
14:13:03 <ndevos> yes, looks like we need that :)
14:13:21 <hagarth> another thing around 3.5 is the other ecosystem projects around glusterfs
14:13:33 <hagarth> should we have a co-ordinated release of such projects?
14:13:35 <johnmark> hagarth: yes
14:13:44 <johnmark> oh wait... hang on
14:13:49 <johnmark> hagarth: yes, we need to discuss that
14:13:53 <hagarth> i am referring to gluster-swift, gluster-deploy, puppet-gluster etc.
14:13:57 <johnmark> hagarth: I think purpleidea will have opinions :)
14:14:12 <purpleidea> johnmark: uh? i do?
14:14:14 <hagarth> we have lpabon also :)
14:14:31 <lpabon> hagarth: i'm not sure if that is possible.  Gluster-swift follows openstack-swift releases
14:14:35 <johnmark> hagarth: yes - we have a board meeting next week to decide on which projects currently meet the standard for graduation
14:14:42 <hagarth> lpabon: agree
14:14:50 <johnmark> lpabon: hrm, ok
14:15:02 <johnmark> lpabon: so releasing it with glusterfs 3.5 is not possible?
14:15:12 <johnmark> lpabon: or simply not recommended?
14:15:15 <purpleidea> i have no problem coordinating a release with gluster. my only issue is i lack vm's or hardware to appropriately test a qa build, or anything that isn't gluster stable (home cluster)
14:15:19 <Technicool> lpabon we could track a separate document for swift and mention it somewhere in the main 3.5 docs
14:15:25 <johnmark> purpleidea: ok
14:15:31 <hagarth> if there are projects which are dependent on 3.5, we can consider having a co-ordinated release. does that make sense?
14:15:41 <lpabon> johnmark: I mean that releasing with 3.5 can just grab whatever has been stabilized.. which may mean a Havana, or Grizzly, or Icehouse release
14:15:50 <johnmark> hagarth: sure. so release 3.5, and then sometime later have a "distribution release"
14:15:53 <johnmark> or whatever we call it
14:15:56 <johnmark> lpabon: ah, ok
14:15:59 <hagarth> johnmark: right
14:16:23 <johnmark> hagarth: we should get the contributors to the candidate projects together and decide on a schedule
14:16:40 <hagarth> johnmark: sounds like a good idea
14:16:41 <johnmark> hagarth: which is something I've been meaning to do
14:16:54 <hagarth> johnmark: ok
14:16:58 <johnmark> #action jmw to convene contributors' meeting
14:17:15 <lpabon> Maybe we can coordinate what versions are available from other projects at the time of a GlusterFS release?
14:17:36 <johnmark> right now, the main candidates are gluster-swift, gluster-hadoop, pmux, and maybe one of gluster-puppet or gluster-deploy
14:17:46 <hagarth> lpabon: yeah, that would be nice to have. We often get questions like how to use project xyz with GlusterFS 3.x
14:17:59 <ndevos> +1 for lpabons idea too
14:18:08 <johnmark> lpabon: hmm... that's a good idea
14:18:17 <hagarth> since we are moving test day by a week, I think we need to move all dates by a week at least.
14:18:22 <johnmark> lpabon: I think we should get some people together next week to hash out a plan
14:18:28 <johnmark> hagarth: +1
14:18:31 <purpleidea> hagarth: is glupy something someone is still going to hack on. looks 7 months old, but very interesting.
14:18:31 <lpabon> Maybe on the release page for a version of glusterfs we can provide a list of versions from other projects?
14:18:35 <hagarth> at least the beta and release dates
14:18:42 <hagarth> lpabon: +1 to that
14:18:42 <lpabon> johnmark: ok, we can do that
14:18:55 <hagarth> purpleidea: yes, glupy is very much hackable
14:18:57 <johnmark> lpabon: that works
14:19:13 <johnmark> purpleidea: jclift was workign on that, and he'll be back from vacation next week
14:19:14 <purpleidea> hagarth: would love to see glupy releases along side gluster main releases. :)
14:19:27 <johnmark> purpleidea: but I don't know where his latest code lives
14:19:32 <lpabon> #action johnmark and lpabon and others to discuss multiple project release coordination
14:19:37 <johnmark> or if he committed it before he left for the month
14:19:40 <hagarth> purpleidea: yeah, that is a good idea
14:19:49 <hagarth> ok, anything else on 3.5 that we want to discuss atm?
14:19:51 <johnmark> purpleidea: yup
14:20:14 <hagarth> looks like we are done with 3.5
14:20:20 <johnmark> hagarth: yay :)
14:20:23 <hagarth> #topic community meeting schedule
14:20:29 <hagarth> so the big question
14:20:51 <hagarth> a) does this time work for a weekly meeting? b) should we have a poll to decide the meeting schedule?
14:21:01 <hagarth> rather big questions :)
14:21:05 <johnmark> hagarth: it works great for me :)
14:21:06 * avati is barely awake at this hour :p
14:21:07 <purpleidea> this time is lousy for me
14:21:10 <johnmark> lol
14:21:17 <Technicool> its a little early for me as well
14:21:31 <johnmark> hagarth: maybe we can have the next one 12 hours later? and alternate between those two?
14:21:31 <purpleidea> but i don't think i'm very important for this sort of thing. i can read logs
14:21:32 <hagarth> I agree that it is difficult for the PST folks
14:21:33 <Technicool> but i can do it if this works better for most people
14:21:35 <johnmark> or is that too confusing?
14:21:58 <hagarth> but when we spring forward, would 7 am be doable for PST folks?
14:22:07 <lalatenduM> johnmark, might get confusing :)
14:22:12 <johnmark> lalatenduM: true :)
14:22:28 <hagarth> johnmark: even I feel that it would be confusing
14:22:34 <johnmark> hagarth: and it will be 10am for me :)
14:22:39 <johnmark> hagarth: fair enough :)
14:22:57 <hagarth> avati, Technicool, gkleiman: are you folks fine with this schedule for the next 3 months or so?
14:22:58 <avati> what are all the various TZs we have people frome today?
14:23:12 <ira> Eastern
14:23:17 <ndevos> I'm in CEST
14:23:17 <gkleiman> fine with me
14:23:21 <lalatenduM> IST
14:23:31 <hagarth> I figure India is the eastern most in the meeting right now
14:23:33 <lpabon> Eastern
14:23:36 <johnmark> yeah, that's quite a span
14:23:37 <purpleidea> avati: EST, not an early bird
14:23:37 <Technicool> hagarth, yes this works ok short term, and long term if need be
14:23:50 <johnmark> hrm... and Paul's not here
14:23:54 <johnmark> gkleiman: ^^^
14:24:08 <hagarth> johnmark: it would be well past midnight in New Zealand :)
14:24:14 <johnmark> oh! heh
14:24:19 * johnmark didn't know that
14:24:24 <gkleiman> true, later would be better to have PaulC on
14:24:25 <hagarth> the farthest we can get east is Japan at this hour
14:24:31 <johnmark> hagarth: ok
14:24:33 <avati> it's 3.30AM for Paul
14:24:38 <johnmark> ouch. never mind
14:24:46 <hagarth> gkleiman: that might affect participation from India and the vicinity
14:24:53 <johnmark> let's face it, no matter what time we choose, it will always suck for somebody
14:25:03 <hagarth> johnmark: yeah
14:25:14 <lpabon> almost seems that we should have two meetings.. maybe centered in India and US time
14:25:16 <Technicool> lets make sure it affects someone we all dont like then...thats the only fair solution
14:25:24 <hagarth> shall we stick with this schedule and re-visit this after a month or so?
14:25:25 <gkleiman> figure out who is critical and plan around them
14:25:30 <purpleidea> Technicool: i vote for this idea ;)
14:25:34 <johnmark> LOL
14:26:00 <johnmark> gkleiman: problem is, critical people are stretched across pacific, eastern US and IST
14:26:18 <hagarth> or is there merit in moving the meeting by an hour to UTC 3 pm ?
14:26:24 <ira> Pacific isn't even the horror... Australia is. :/
14:26:30 <lpabon> One meeting could be first, and the second could review the actions and notes from the previous and continue the discussions.  Maybe PLs could then combine the minutes?
14:26:39 <johnmark> lpabon: that's a splendid idea
14:26:52 <johnmark> and perhaps the only workable solution
14:27:08 <hagarth> lpabon: yeah, that might be a possibility.
14:27:18 <hagarth> shall we reach there once we have more participation?
14:27:18 <gkleiman> Would AM India, afternoon Pac, and evening Eastern time work better
14:27:42 <gkleiman> this would allow you to include NZ
14:27:46 <hagarth> gkleiman: we will miss out ndevos and folks in EU then
14:27:54 <lpabon> I really cannot do evenings thats Wife time :-)
14:28:00 <hagarth> okay, here's my proposal:
14:28:10 <hagarth> 1. we stick to this time for the next month
14:28:18 <hagarth> 2. tune if necessary after that
14:28:38 <gkleiman> +1
14:28:43 <avati> s/1.*/1. stick to this time+1hr for the next month/ ?
14:29:13 <lalatenduM> agree with avati
14:29:25 <hagarth> ok. time + 1 for the next month (3 PM UTC)
14:29:32 <johnmark> hagarth: got it
14:29:38 * msv agrees
14:29:40 <hagarth> I will send out invites for that
14:29:45 <johnmark> hagarth: thank you :)
14:29:46 <ndevos> works for me :)
14:29:50 <johnmark> ps - what about 3.4.2?
14:29:52 <hagarth> #action hagarth to send out revised invites.
14:29:55 <johnmark> hagarth: ^^^
14:29:57 <hagarth> #topic 3.4.2
14:30:06 <johnmark> ok
14:30:10 <hagarth> patches are trickling in for 3.4.2
14:30:20 <hagarth> we need some more help with dht backports
14:30:31 <hagarth> there seem to be a few issues with rebalance in 3.4.1
14:30:34 <purpleidea> i vote johnmark helps with the dht backport ;)
14:30:43 <hagarth> and all of them seem to have been addressed with mainline/3.5qa1
14:30:56 <johnmark> purpleidea: lol :P
14:31:04 <hagarth> purpleidea: +1 ;)
14:31:06 <johnmark> hagarth: so who can help backport that?
14:31:11 <johnmark> hagarth: ie. not me :)
14:31:20 <johnmark> hagarth: trust me, nobody wants that
14:31:32 <hagarth> johnmark: I will talk to the dht developers to see if we can have them soon
14:31:39 <johnmark> hagarth: ok, thank you
14:31:45 <hagarth> but I worry that we might have to do a lot of backports to 3.4.2
14:31:55 <lalatenduM> hagarth, do think I can help with the backports ? I mean , am I qualified enough?
14:32:12 <hagarth> lalatenduM: you certainly are
14:32:27 <lalatenduM> hagarth, awesome :), I will try to do some
14:32:29 <hagarth> lalatenduM: me and avati can offer assistance there
14:32:37 <ndevos> hagarth: is there a list of patches that need backporting?
14:33:10 <hagarth> ndevos: the crux is in identifying the list. I know that few members in the community have been actively bisecting to determine what all are necessary.
14:33:20 <avati> we already have enough backports to spin out a 3.4.2qa1 while the other patches come in
14:33:30 <ndevos> ok
14:33:37 <hagarth> ndevos: for example - https://bugzilla.redhat.com/show_bug.cgi?id=1033576
14:33:39 <glusterbot> Bug 1033576: unspecified, high, ---, sgowda, NEW , rm: cannot remove  Directory not empty on path that should be clean already
14:33:42 <hagarth> avati: agree
14:33:57 <hagarth> let us get 3.4.2qa1 out and continue working on backports
14:33:59 <johnmark> avati: then we should do that
14:34:09 <johnmark> but we need to set a deadline for more patch merges
14:34:16 * avati fires up a build in parallel
14:34:20 <johnmark> hagarth: can we create some processes around fixes committed to master?
14:34:42 <johnmark> hagarth: so that we're not continually trying to run down patches to be backported?
14:34:44 <avati> johnmark: what kind of process are you suggesting for fixes committed to master?
14:34:46 <hagarth> johnmark: yes, we need dedicated release maintainers who keep pollign master regularly
14:34:53 <avati> ah
14:35:03 <johnmark> it would seem that anyone who commits patches has a responsbility ot apply backports if it's an open bug
14:35:04 <avati> i see what you mean
14:35:15 <hagarth> if there's any interest for release-3.5, please mail me indicating your interest to do so
14:35:21 <johnmark> avati: otherwise, we always have this problem of trying ot contain the patch management beast
14:35:24 <avati> I was thinking of an rfc.sh enhancement asking a Y/N for a possible backport
14:35:37 <johnmark> avati: oh - that might help
14:35:39 <hagarth> avati: not all patches would be straightfoward backports
14:35:43 <ira> johnmark: Not all bug fixes back port... I'm more along with avati here.
14:35:44 <johnmark> hagarth: true
14:35:50 <johnmark> ira: ok
14:36:11 <avati> hagarth: it's to just tag the commit id for someone to scrub git log
14:36:27 <hagarth> in any case, if you need more patches to be included in 3.4.2, please add it here - http://www.gluster.org/community/documentation/index.php/Backport_Wishlist
14:36:34 <johnmark> avati: right. we need some way to identify whihc ones are candidates for backporting
14:36:40 <ira> Usually, the people committing the bug, have an interest in the backport, and open up the BZ for the backport.
14:36:45 <johnmark> hagarth: thanks. we need to circulate that
14:36:55 <hagarth> avati: sounds like a good idea
14:36:55 <johnmark> ira: right
14:37:11 <ndevos> the Linux kernel uses a stable@ email address to CC important bugfixes, I guess ./rfc.sh can do something similar indeed
14:37:28 <avati> ndevos: yep, that was the inspiration
14:37:30 <hagarth> shall we set a tentative date of Dec 10th for 3.4.2?
14:37:54 <hagarth> any volunteers for the rfc.sh enhancement?
14:38:08 <avati> hagarth: I'll do it
14:38:15 <hagarth> avati: thanks
14:38:38 <hagarth> #action avati to enhance rfc.sh to aggregate patches that need to be backported
14:38:55 <hagarth> any opinions on the 3.4.2 date? too early, late or seems right?
14:39:07 <johnmark> hagarth: sounds about right, with the usual caveats
14:39:20 * ndevos has no opinion
14:39:25 <hagarth> johnmark: thanks, let us target that
14:39:42 <johnmark> now to start spinning up the testing day things...
14:39:50 <hagarth> any other 3.4.2 related discussions?
14:40:26 <hagarth> i guess not
14:40:26 * lalatenduM has nothing discuss more
14:40:36 <hagarth> #open discussion
14:40:42 <hagarth> #topic open discussion
14:40:43 <hagarth> rather
14:40:56 <johnmark> hagarth: thank you for taking this on
14:41:12 <purpleidea> i guess i have one question/comment or two
14:41:14 <johnmark> hagarth: also, dec. 10 is the date for GA of 3.4.2, right?
14:41:17 <johnmark> purpleidea: roll it
14:41:22 * purpleidea rolls
14:41:22 <hagarth> johnmark: right
14:41:59 * johnmark looks at his watch
14:42:06 <hagarth> purpleidea: go ahead
14:42:39 <hagarth> ok, some quick updates on happenings around the gluster world
14:42:46 <purpleidea> obviously my interest is puppet-gluster; how important is this to gluster community. if so, i've asked before, but are there vm's i can get access to to test, or budget for some cheap iron i can buy?
14:43:04 * hagarth holds back
14:43:05 <johnmark> purpleidea: there are two possibilities
14:43:22 <johnmark> purpleidea: 1. we have a rackspace account that you could use to spin up some VMs, but that's on a smaller scale
14:43:50 <johnmark> purpleidea: 2. there's the OSUOSL, which might have the capability you're looking for. I can intro you to Lance there
14:44:16 <purpleidea> i would need 2-5 vm's max for testing, occasionally a few more to try some fancy things. they can be cheap and small, i don't care about performance.
14:44:25 <johnmark> purpleidea: actually, there are others, but they're not yet ready, including a large data center here in Massachusetts that's looking to be a testing ground for things like that
14:44:34 <purpleidea> joe tried to set something up with lance, but we haven't heard back since linuxcon
14:44:40 <gkleiman> purpleidea: Please coordinate with PaulC (Cuzner) since he is pursuing similar work
14:44:40 <johnmark> purpleidea: oh, we can accomodate that
14:45:06 <hagarth> gkleiman: +1, purpleidea I can loop you in with Paul Cuzner
14:45:08 <purpleidea> gkleiman: can you do an intro about this topic by email for me?
14:45:19 <johnmark> #action jmw to coordinate with purpleidea and Paul Cuzner re: testing facilities
14:45:20 <purpleidea> hagarth: that would be great
14:45:48 <hagarth> ok, quick updates from gluster world
14:45:59 <hagarth> ganeti folks are looking to integrate with glusterfs - http://docs.ganeti.org/ganeti/master/html/design-glusterfs-ganeti-support.html
14:46:45 <lalatenduM> hagarth, yup
14:46:51 <ndevos> excuse my ignorance, but what is genati, in one sentence please?
14:47:22 <hagarth> ndevos: ganeti is a virtualization management stack
14:47:27 <johnmark> ndevos: think virt/cloud management, a la ovirt, cloudstack, et al
14:47:34 <ndevos> ok!
14:47:37 <purpleidea> ndevos: but google
14:47:49 <ira> google created it for their own test labs a while back...
14:47:50 <johnmark> ndevos: and the OSUOSL has a rather large deployment with GlusterFS
14:48:11 <hagarth> archipelago project also has started integrating with glusterfs - https://code.grnet.gr/projects/archipelago
14:48:15 <johnmark> ndevos: hence OSL's interest in this by sponsoring a GSOC engineer to work on it
14:48:42 <hagarth> ndevos: would you want to provide a quick update on the cloudstack work that you were involved with last week?
14:49:13 <ndevos> ah, yes, last week there was a CloudStack hackathon in Amsterdam at the CloudStack Conference
14:49:36 <ndevos> I've discussed a little with some CloudStack devs, who explained how to integrate Gluster
14:50:10 <avati> is this for using gluster as a vm store?
14:50:14 <ndevos> at the moment, I can create a Primary Pool (for VM storage) in CloudStack - but I broke other bits in the process
14:50:28 <ndevos> yes, avati, but also as secondary pool
14:50:48 <avati> ok..
14:50:58 <johnmark> guys - have to check out for a bit. Will check in later and read notes, IRC buffer
14:50:59 <ndevos> currently NFS and S3 are available as secondary pool, but the CloudStack people would like to see Gluster there too
14:51:30 <ndevos> source and start of the docs at: https://forge.gluster.org/cloudstack-gluster/pages/Home
14:51:42 <hagarth> there is also some interest to integrate with Xen (along the lines of qemu-kvm - libgfapi), if anybody is interested please let us know
14:52:12 <hagarth> ndevos: cool, seems like an interesting project.
14:52:14 <avati> does xen have a block layer plugin architecture?
14:53:08 <hagarth> avati: the same qemu - libgfapi integration should be consumabe by Xen but it requires some plumbing in libxl
14:53:15 <ndevos> and, of course anyone who likes to contru=ibute to the CloudStack integration (Java + JavaScript) or testing is welcome!
14:53:24 <hagarth> libxl is the equivalent/fork of libvirt that xen use
14:53:29 <hagarth> *xen uses
14:53:54 <hagarth> any other updates for today?
14:54:04 <purpleidea> one more q
14:54:08 <hagarth> purpleidea: sure
14:54:31 <purpleidea> is this the right venue to propose a technical feature (that i have some code for?)
14:54:31 <avati> was that a recent enhancement in qemu, to plumb the block drivers into xen?
14:54:52 <hagarth> purpleidea: sure
14:55:03 <purpleidea> hagarth: okay, i actually have two. (very quick)
14:55:32 <hagarth> avati: i believe there is a mechanism, but we need to double check the exact details.
14:55:36 <hagarth> purpleidea: go ahead
14:55:52 <purpleidea> 1) i've been looking into how an admin automatically adds/removes nodes for large pools without having to compute the add/remove command ordering. would also be awesome if it worked for chained commands. as a result, i've got testcases and logic to try and do this.
14:56:15 <purpleidea> it would also be awesome if there is a notion of a "standardized" brick naming scheme, and ordering. see: http://paste.fedoraproject.org/57200/56401813
14:56:23 <purpleidea> for a very rough draft i'm hacking on now.
14:57:08 <hagarth> purpleidea: sounds like a good idea, i think this would make a nice discussion on gluster-devel
14:57:24 <purpleidea> hagarth: okay
14:57:36 <avati> purpleidea: these are some topics which touch upon in the glusterfs 4.0 plan as well - FYI (i'm due to sending out the draft)
14:57:50 <hagarth> yay for 4.0!
14:57:51 <purpleidea> hagarth: 2nd comment. i've been looking at gluster+reflinks. has anyone looked at this? i have a lot of ideas.
14:58:14 <purpleidea> (would need a compatible brick fs like btrfs for example)
14:58:18 <ndevos> reflinks?
14:58:31 <avati> purpleidea: i've been following reflink dev.. i don't think the syscall interface is finalized yet?
14:58:37 <purpleidea> avati: it is
14:58:40 <hagarth> purpleidea: not that i am aware of. The btrfs integration with 3.5 will make it more visible.
14:58:46 <avati> oh cool
14:58:48 <ira> avati: In fact samba is using it.  :)
14:58:57 <purpleidea> in fact, i've written a draft write up about why this is THE killer feature. comments welcome: http://ttboj.wordpress.com/?p=482&shareadraft=5296088f6f9cc
14:59:03 <purpleidea> (actually, comments would be appreciated)
14:59:06 <avati> ira: is it using the btrfs specific ioctl() or is there a generic reflink syscall now?
14:59:08 <purpleidea> avati: i could be wrong though
14:59:27 <ira> avati: I can check.  I know they've been plumbing like mad.
15:00:00 <hagarth> purpleidea: nice, will have some comments
15:00:02 <purpleidea> ira: avati: i remember reading through all the mailing list patches. it looked finalized. cp --reflink exists
15:00:23 <hagarth> ok, that brings us to the top of the hour.
15:00:25 <purpleidea> hagarth: would very much appreciate knowing how feasible this is. if it is, i guarantee this is the #1 feature any sysadmin would want.
15:00:33 <hagarth> purpleidea: sure
15:00:40 <purpleidea> hagarth: appreciate it, thanks
15:00:44 <avati> purpleidea: i was thinking of introducing a reflink-like FOP which would be the interface for making clones. that will by deafult call into the backend's reflink mechnaism, or get intercepted by BD for its cloning or qemu-block for its external snapshots
15:00:44 <hagarth> shall we end the meeting and convene again next week?
15:00:59 <avati> ira: cp --reflink makes btrfs specific ioctl(), not a generic syscall
15:01:00 <lalatenduM> yup
15:01:03 <hagarth> thanks everybody for joining in
15:01:06 <hagarth> #endmeeting