Camelia, the Perl 6 bug

IRC log for #gluster-dev, 2013-08-28

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:03 asias joined #gluster-dev
01:25 bala joined #gluster-dev
02:25 bharata-rao joined #gluster-dev
02:25 asias joined #gluster-dev
02:31 awheeler joined #gluster-dev
02:36 awheeler joined #gluster-dev
02:40 lalatenduM joined #gluster-dev
02:54 bulde joined #gluster-dev
03:20 bala joined #gluster-dev
03:25 shubhendu joined #gluster-dev
03:31 hagarth joined #gluster-dev
03:43 ndarshan joined #gluster-dev
03:50 vshankar joined #gluster-dev
03:59 itisravi joined #gluster-dev
04:02 awheeler joined #gluster-dev
04:06 aravindavk joined #gluster-dev
04:11 ppai joined #gluster-dev
04:13 spandit joined #gluster-dev
04:23 mohankumar joined #gluster-dev
04:51 kanagaraj joined #gluster-dev
04:55 rjoseph joined #gluster-dev
05:20 raghu joined #gluster-dev
05:27 mohankumar joined #gluster-dev
05:33 mohankumar__ joined #gluster-dev
05:42 lalatenduM joined #gluster-dev
05:46 ababu joined #gluster-dev
05:48 lalatenduM joined #gluster-dev
06:13 bulde joined #gluster-dev
06:30 mohankumar__ joined #gluster-dev
07:07 kanagaraj joined #gluster-dev
07:16 ndevos hello rjoseph: could you re-add your +1 or +2 on http://review.gluster.org/4430 please?
08:45 mohankumar__ joined #gluster-dev
08:47 msvbhat joined #gluster-dev
08:49 shubhendu joined #gluster-dev
08:52 raghu left #gluster-dev
09:04 edward1 joined #gluster-dev
09:47 shubhendu joined #gluster-dev
09:53 rjoseph joined #gluster-dev
10:38 rjoseph joined #gluster-dev
11:09 ababu_ joined #gluster-dev
11:19 hagarth joined #gluster-dev
11:20 bala joined #gluster-dev
11:31 kshlm joined #gluster-dev
12:12 mambru joined #gluster-dev
12:17 hagarth joined #gluster-dev
12:30 rgustafs joined #gluster-dev
12:36 awheeler joined #gluster-dev
12:37 awheeler joined #gluster-dev
12:55 kaushal_ joined #gluster-dev
13:00 hagarth joined #gluster-dev
13:03 bulde1 joined #gluster-dev
13:09 ppai joined #gluster-dev
13:16 ababu_ joined #gluster-dev
13:18 hagarth @startmeeting
13:19 hagarth #startmeeting
13:28 deepakcs joined #gluster-dev
13:33 rjoseph joined #gluster-dev
13:36 gluster-meetb0t joined #gluster-dev
13:37 rajesh ndevos: accepted the review
13:37 hagarth #startmeeting
13:38 ndevos rjoseph/rajesh/Guest84663: thanks!
13:38 Guest84663 :)
13:38 hagarth #endmeeting
13:38 ndevos oh, it looks like we're done?
13:39 ndevos short meetings are awesome!
13:39 hagarth ndevos: am testing the bots :)
13:39 rjoseph wow!
13:39 ndevos hagarth: I thought so :)
13:39 ndevos hagarth: oh, are you or is it avati who can fixup users in gerrit?
13:40 ndevos I seem to have 2 accounts, sometimes a review request gets sent to the wrong one :-/
13:41 hagarth ndevos: I have the same problem too
13:42 aravindavk joined #gluster-dev
13:42 ndevos hagarth: https://gerrit-review.googlesource.co​m/Documentation/cmd-set-account.html might be able to fix that
13:42 ababu_ joined #gluster-dev
13:46 hagarth ndevos: will check that
13:47 ndevos hagarth: thanks, no need to rush, it only bothers me on occasion :)
13:47 gluster-meetb0t joined #gluster-dev
13:48 kkeithley ndevos: yes, it's annoying that I can't add you by your ndevos@redhat, I have to remember to use your nixpanic email
13:48 kkeithley vbellur@redhat has the same problem
13:49 kkeithley iirc
13:49 Guest84663 joined #gluster-dev
13:50 ndevos kkeithley: somehow that address is connected to my fedora-openid account *and* my normal nixpanic one - I hope that disabling the fedora account makes it work
13:50 Guest84663 left #gluster-dev
13:51 Guest84663 joined #gluster-dev
13:54 kkeithley changing subjects, it's always — shall we say, enlightening — to use a different compiler on a project. FWIW I tried AMD's opencc on master/HEAD and in about a minute found a couple things. One of them might be a real issue in stripe.
13:56 avati ndevos: you have two accounts in gerrit?
13:57 ndevos avati: yeah, I think so
13:57 hagarth avati: the dropdown lists multiple accounts
13:57 kkeithley autocomplete pops up three ndevos@redhat for me
13:57 avati duplicate accounts got created when we renamed review.gluster.com to review.gluster.org
13:58 ndevos okay, but can these not be disabled/removed?
13:58 avati checking
13:59 jdarcy joined #gluster-dev
13:59 vshankar joined #gluster-dev
13:59 keith_ joined #gluster-dev
14:00 hagarth hello everyone
14:00 mohankumar__ hi hagarth
14:00 portante is the 3.5 planning meeting going to happen now?
14:00 avati hey guys
14:00 vshankar hey hagarth
14:00 jdarcy Hi Vijay.
14:00 avati portante: yep
14:00 hagarth the bots are misbehaving today, so my tags would indicate start, agenda and end of meeting today
14:00 jdarcy ...and Avati.
14:00 hagarth so please do bear with me :)
14:00 avati hey jeff
14:00 rjoseph hi all
14:01 hagarth #startmeeting
14:01 keisuke_ hi there
14:01 avati hello keisuke_!
14:01 * portante waves hi
14:01 keisuke_ hello!
14:01 hagarth #agenda
14:01 aravindavk hi all
14:01 hagarth 1. Categorization of Features into 'Core' and 'Nice to Have'
14:01 kshlm hi all
14:01 hagarth 2. Establish feature acceptance criterion
14:02 portante is there an etherpad listing all these features?
14:02 hagarth http://www.gluster.org/community/d​ocumentation/index.php/Planning35
14:02 hagarth has all the features listed
14:02 jclift joined #gluster-dev
14:02 rfortier joined #gluster-dev
14:03 jclift Sorry I'm late, just had the meeting reminder pop up
14:03 hagarth okay, let us get started with features that are listed in the same order as the planning35 page
14:03 hagarth jclift: we are just about getting started
14:03 jclift :)
14:03 hagarth 1. AFR_CLI_enhancements
14:04 avati any of the three around?
14:04 hagarth I don't think we have Raghav here but he dropped a note saying that it would be doable by October and hence good to target it for Core
14:04 avati OK
14:04 * portante be back in 10 minutes, sorry
14:05 hagarth this is the live etherpad that accompanies the meeting - http://titanpad.com/xL7AGRkjVJ
14:05 hagarth 2. Better peer identification - kshlm are you around?
14:05 kshlm here
14:06 jdarcy I vote for core, just because it's a prereq for multi-network handling and that can't stay out too much longer.
14:06 vshankar joined #gluster-dev
14:06 hagarth my vote is for that too
14:06 hagarth kshlm: are you comfortable with that status?
14:06 kshlm core for me too.
14:07 hagarth kshlm: thanks
14:07 hagarth 3. Brick Failure Detection
14:07 hagarth that is my feature. I propose it to be for Nice to have
14:08 jdarcy Concur.
14:08 hagarth jclift: will you keep updating the etherpad?
14:08 avati is this related to ndevo's patch too?
14:08 jclift hagarth: Sure, can do
14:08 hagarth avati: yes, and we would need a bit more orchestration for that.
14:08 hagarth jclift: thanks!
14:08 jclift Was AFT CLI enhancement accepted?
14:08 avati yep
14:08 hagarth okay, moving on
14:09 hagarth 4. Easy addition of custom translators
14:09 jclift Ahh, that ones mine.
14:09 jclift It's an initial concept proposal, but I personally don't have the time/skill to implement it for 3.5
14:09 hagarth jclift: Nice to Have then?
14:09 jclift I'm kind of hoping someone else has the inclination to pick this up and code it
14:09 jdarcy Sadly, I'd put it at "nice to have"
14:09 jclift Nice to have then
14:10 hagarth okay
14:10 avati yes, nice to have, and i would propose myself to be an additional owner
14:10 avati updated the wiki
14:10 hagarth avati: sounds good, thanks,
14:10 jclift Btw, for the etherpad does should "Accepted" == "Must have / Core planned feature" ?
14:11 hagarth jclift: yes, that would be correct
14:11 hagarth moving on
14:11 hagarth 5. better-ssl
14:11 wushudoin joined #gluster-dev
14:11 hagarth jdarcy: any thoughts on that?
14:12 jdarcy This is one of mine.  The management-plane needs to be core IMO, the rest maybe not.  Perhaps split?
14:12 hagarth if we can do the split, it does seem like a good proposal.
14:12 avati jdarcy: for management-plane does it involve auth using ssl certs?
14:13 avati *does the scope involve
14:13 jdarcy avati: As an option, yes.
14:13 avati it would certainly be nice to get that in.. i too vote for splitting and getting glusterd changes as core
14:14 jdarcy avati: In other words, one option controls whether we trust plain usernames or require them to be SSL-authenticated.  Other options control how we use those names and/or require passwords to go with them.
14:14 avati jdarcy: ok
14:14 VivekAgarwal joined #gluster-dev
14:15 jdarcy OK, so note the split and move on?
14:15 avati +1
14:15 jclift jdarcy: Thanks.  I was just about to ask you to do that :)
14:16 jdarcy Data Classification is another of mine.  I think it's *really* nice to have, but I can't commit to doing it in a 3.5 timeframe.
14:17 jdarcy Maybe we need a LookingForOwner status.  ;)
14:17 avati :D
14:17 hagarth joined #gluster-dev
14:17 hagarth okay, a bad network threw me off :)
14:18 gluster-meetb0t joined #gluster-dev
14:18 hagarth where are we right now?
14:18 jclift About to start with disk-encryption
14:18 avati < jdarcy> Data Classification is another of mine.  I think it's *really* nice to have, but I can't commit to doing it in a 3.5 timeframe.
14:18 jdarcy hagarth: data classification is NtH, on to disk encryption
14:18 avati in case you missed it
14:18 hagarth avati, jdarcy: thanks
14:19 hagarth i figure disk encryption will be similar to data classification?
14:19 jdarcy I don't know what to make of this one.  It's really Edward's at this point.
14:19 jdarcy Impact uncertain, effort high.
14:20 hagarth let us park it in Nice to Have
14:20 jdarcy OK
14:20 avati is Edward around?
14:20 avati here
14:20 hagarth doesn't look like
14:20 hagarth moving on
14:20 avati edward1 ?
14:20 avati ok
14:20 jdarcy Connected but apparently idle (probably AFK)
14:20 avati moving on
14:20 hagarth disperse
14:20 hagarth xavi mailed me off list to indicate that this would be nice to have
14:20 jdarcy Impact high, completion/commitment high.  I'd say Core.
14:21 avati Xavi want's it nice to have..?
14:21 hagarth given xavih prefers it to be in NTH, I feel we could park it there.
14:21 jdarcy But Xavi knows better than I do.
14:22 jdarcy As a policy matter, I don't think we should make anything core against the owners' advice.
14:22 hagarth jdarcy: agree
14:22 hagarth so NTH it is
14:22 hagarth moving on
14:22 hagarth Exports_Netgroups_Authentication
14:23 hagarth don't think Richard and/or Shreyas are here
14:23 hagarth they mentioned that a working code is ready  but since they are not around
14:23 jdarcy Well-written proposal.  :)
14:23 hagarth I would put it under NTH till we here otherwise.
14:23 hagarth s/here/hear/
14:23 avati it's a cool feature though
14:24 jclift Nice to have then?
14:24 jclift k
14:24 avati yeah
14:24 hagarth ok, moving on
14:24 hagarth exposing-volume-capabilities
14:24 mohankumar__ hagarth: i have the code ready, in 1-2 days, i will post the patch(eS)
14:25 hagarth mohankumar__: great, so can we consider this as a core feature?
14:25 jdarcy I'd say core, because it's going to be infrastructure for future efforts.
14:25 mohankumar__ hagarth: yeah, its a core feature
14:25 jclift It sounds very very useful
14:25 hagarth jdarcy: agree, it sounds like a neat thing to have.
14:25 hagarth ok, core it is then.
14:25 mohankumar__ it will be nice if people respond to my patch about how we expose the capability
14:25 mohankumar__ so we can finalize the *interface*
14:25 hagarth mohankumar__: sure, I will help there.
14:26 avati mohankumar__: patch / email?
14:26 mohankumar__ avati: any thing ok
14:26 mohankumar__ i have the patches, still under testing
14:26 hagarth ok. moving on
14:27 hagarth File_Snapshot
14:27 avati oh, I just meant to ask when you aid you were waiting for a response to your patch, i couldn't find any on gerrit
14:27 jdarcy Core.  This could be our marquee feature.
14:27 avati file_snapshot - core
14:27 hagarth agree there
14:28 hagarth ok, core it is then.
14:28 avati internal snapshot is almost comittable (minor review comments), and bfoster might also be helping in implementation of external snaps
14:28 mohankumar__ avati: sorry for the confusion, i will post the patch supporting exporting capabilities soon
14:28 hagarth avati: do we consider both as core?
14:28 avati mohankumar__: thanks
14:28 hagarth both internal and external?
14:29 avati hagarth: I think so
14:29 avati just internal is not very useful as you cannot make clones
14:29 hagarth avati: right, so file snapshot is a core feature.
14:29 hagarth moving on
14:29 hagarth Geo-replication to Swift Target
14:30 jdarcy TBH I just don't get this one.
14:30 hagarth Andrew indicated that he is tentative
14:30 * portante agrees with jdarcy
14:30 jclift NIH then
14:30 portante what is the use case?
14:30 avati using swift as a backup I guess
14:30 jdarcy jclift: Freudian slip?
14:30 jdarcy NIH vs. NTH
14:30 jclift Heh
14:30 hagarth yeah, NTH pending more clarity.
14:31 hagarth moving on
14:31 hagarth gfid-access
14:31 portante can we rename this to geo-replication over untrusted networks (the swift one?)
14:31 avati Amar around?
14:31 hagarth portante: we possibly could
14:31 edward1 avati: Yup, I am here
14:32 hagarth avati: bulde mentioned that since the feature is almost ready, we could treat it as core.
14:32 avati edward1: we have currently classified disk encryption as "nice to have" for 3.5. would you like to comment?
14:32 avati hagarth: yes, i agree. it can be core
14:33 jclift portante: For clarity "Geo-replication to Swift Target" -> "Geo-replication over untrusted networks" ?
14:33 kkeithley portante: so is Swift even involved?
14:33 hagarth ok, gfid-access is a core feature as we have very little risk in pulling it off.
14:34 portante kkeithley: the requirement from reading the page on the feature seems to be considering swift as a means to an end
14:34 hagarth jclift, portante: can we have a discussion with Andrew on gluster-devel?
14:34 portante yes
14:34 hagarth portante: thanks, that should help us get more clarity.
14:34 hagarth moving on
14:34 hagarth Multi-Node Test Suite
14:34 jclift Ahh, that's mine
14:35 jclift I feel we can get it up and running for 3.5
14:35 jclift I don't think we should attempt to _replace_ the existing test suite in this time frame though
14:35 hagarth jclift: if we can, I would like to have it as a core feature
14:35 jclift We don't necessarily know if it would be a good _replacement_
14:35 jclift But, I'm happy to have it as a core feature
14:35 keisuke_ +1
14:35 hagarth jclift: agree, this can be an independent effort. the existing tests would still be useful for our smoke/regression tests.
14:36 jclift And, if it turns out after the implementation that we want to use it as a replacement, then we can think about it
14:36 jclift Sure
14:36 kkeithley you could add to https://engineering.redhat.com/rt/Ti​cket/Display.html?id=236229&amp;resu​lts=676e041a39315ee31ce981311b027e3e to get eng-ops to move on setting hardware up
14:36 jclift Interesting
14:36 hagarth ok, core it is then.
14:36 sijoe joined #gluster-dev
14:36 avati kkeithley, jclift would that have publicly visible test results?
14:36 hagarth moving on
14:36 hagarth multiple-namespaces
14:36 jclift avati: Absolutely.
14:37 avati jclift: i meant if we got the hardware setup in-house at Red Hat with eng-ops
14:37 jdarcy This is really more Kaleb's than mine at this point.  Any thoughts, K?
14:37 kkeithley I should be good for multiple namespaces. And on that topic, who can I guilt into reviewing client_t phase 2.
14:37 jclift avati: Actually, mine is for publicly available stuff.  Anything to do with the internal RH QE involvement is 2ndry to my purpose
14:37 kkeithley It's fairly small and easy to digest
14:37 hagarth kkeithley: I volunteer for reviewing phase 2 of client_t.
14:37 jclift avati: So, the in house hw stuff is kind of a separate (though useful) issue
14:37 jclift avati: We can discuss later, etc :D
14:38 kkeithley I was told we can expose that hardware to the outside for things like jenkins builds and I presume for testing
14:38 kkeithley for testing too
14:38 jclift Interesting.  :)
14:38 hagarth kkeithley:  would we be able to do all of what we want to do by the code freeze date?
14:39 hagarth kkeithley: are there other deliverables planned apart from client_t phase 2?
14:39 kkeithley good question. I'll go twist some arms in eng-ops and see what they say about a date
14:39 edward1 avati: The All-in-one translator version is almost completed, I hope to push it to gerrit this week. So yes, let's consider it as "nice to have in 3.5"
14:39 avati multiple namespaces - there's a lot to pull off w.r.t rebalance and self-heal daemons to see all namespaces.. I propoose tech preview as core?
14:39 kkeithley oh, did you mean multiple namespaces?
14:40 hagarth kkeithley: referred to both
14:40 jdarcy avati: Would it be fair to say that "TP as core" is functionally NtH?
14:40 hagarth looks like a candidate for NtH
14:40 kkeithley avati: sure
14:41 kkeithley sure, tech preview as core
14:41 jclift Hmmm, does multiple namespaces have any interaction with the disk encryption proposal
14:41 avati jdarcy: possibly.. I thought NtH could also find "nothing got delivered" as acceptable
14:41 jclift eg they won't step on each other badly?
14:41 avati whereas Tech Preview means something will get delivered..?
14:42 hagarth avati: that seems like a third category :)
14:42 jdarcy jclift: They won't step on each other badly.  There are places they intersect, but not in awful ways.
14:42 avati I'm OK with it being NtH
14:42 jclift Cool :)
14:42 hagarth ok. NtH then.
14:42 hagarth moving on
14:42 hagarth new-style-replication
14:42 jclift k, so "multiple-namespaces" is NTH.  What's the "all-in-one translator" thing ?
14:43 hagarth jclift: NtH as well.
14:43 kkeithley all-in-one-translator is on-disk encryption
14:43 vshankar hagarth: NSR would be NTH
14:43 jclift Is it on the proposal list?
14:43 hagarth jclift: yes
14:43 * jclift just wants to know where to update status/links for it
14:43 jclift Features/disk-encryption
14:43 jclift ?
14:43 kkeithley yes
14:43 hagarth jclift: yes
14:43 * portante has to run, hopes "File Count" will get marked as Core as g4us needs it to scale
14:43 edward1 jclift: The first version of transparent encryption was implemented via 2 translators, one on client and one on the server
14:43 jclift k.  I'm good.
14:43 hagarth vshankar: okay, sounds good
14:43 jclift Keep going
14:44 hagarth so NSR is NtH.
14:44 hagarth moving on
14:44 avati NSR owner is listed as Jeff
14:44 jdarcy OK by me.
14:44 hagarth Object_Count
14:44 hagarth ok, all of us seem to be in agreement :)
14:44 avati OK then, I had seen saw Venky's comment so far.. we're in agreement
14:44 hagarth object_count is my feature, I propose it for core
14:44 jdarcy avati: I'm going to push hard for NSR to be done in that time frame, but for planning purposes I think making it Core introduces schedule risk.
14:45 jdarcy hagarth, what's the use case for object count?
14:45 avati jdarcy: yep.. OK
14:46 kkeithley object count is a speed-up for Swift
14:46 hagarth jdarcy: Gluster for Swift would benefit by that, it needs to understand the number of objects in a gluster volume
14:46 jdarcy OK.  Sounds like core then.
14:46 jclift Is object count supposed to be recursive?
14:46 avati yep
14:46 hagarth jclift: yes, it will be recursive.
14:47 kkeithley cumulative?
14:47 hagarth are we all in agreeement on object_count?
14:47 jclift Sounds hairy for large filesystems with a lot of change
14:47 hagarth kkeithley: yeah, cumulative is more apt.
14:47 keisuke_ agree.
14:47 jclift But, not against it.  You guys know this stuff better than me :D
14:47 avati jclift: it's a minor change to marker xlator
14:47 hagarth jclift: this would involve extending the marker framework
14:47 jdarcy Basically extending what we already do for xtime, right?  So no new performance impact?
14:48 hagarth jdarcy: not a significant risk. will have some performance numbers as part of the commit.
14:48 avati we already aggregate size.. now assume every file is always 1 byte.. conceptually :)
14:48 jdarcy Heh.
14:49 hagarth ok. parking it as core and moving on.
14:49 hagarth On-Wire Compression/Decompression
14:49 jdarcy I'd feel better about saying Core if I had some idea of the performance implications.
14:49 vshankar hagarth: compression can be core
14:49 jdarcy (that was re: compression)
14:50 hagarth vshankar: would this involve the pluggable framework for compression too?
14:50 avati as long as there is no impact on performance when the feature is disabled it should be OK
14:50 vshankar hagarth: yes, that would be pluggable - but only zlib as of now :)
14:50 jclift It says it uses zlib for the moment.  Using compression level of 0 to test if it's "no impact" shouldn't be hard
14:50 jclift ?
14:50 hagarth vshankar: ok :)
14:50 kkeithley is compression not done in a translator that's in the stack or out of the stack depending?
14:51 asias joined #gluster-dev
14:51 avati kkeithley: it is a translator
14:51 hagarth kkeithley: it is in the stack as per the proposal
14:51 * kkeithley should RTFP
14:51 jclift http://www.gluster.org/community/documentatio​n/index.php/On-Wire_Compression/Decompression
14:51 avati why does the proposal read On-Wire
14:51 hagarth core if no performance impact if the xlator is disabled?
14:52 avati can't it be loaded on the server side for just on-disk?
14:52 jdarcy avati: Interesting.  Could/should that be a separate proposal?
14:52 jclift On disk would be a different beast wouldn't it?
14:52 jbrooks joined #gluster-dev
14:52 * vshankar agrees with jclift
14:53 hagarth we seem to be running short on time, shall we carry on this discussion on the ML?
14:53 jclift compression of stripe data sounds complicated
14:53 kkeithley jclift: I don't see why, off hand
14:53 avati the patch submitted on gerrit is agnostic as far as i see
14:53 avati ok
14:53 avati let's move on
14:53 jdarcy I think I'd make *that* proposal core.  TBH I'm a bit dubious about whether on-wire compression is likely to be helpful in the network/latency milieu we'll occupy going forward.
14:53 hagarth ok, core it is then.
14:53 vshankar avati: how would it work with overlapping write offsets?
14:53 hagarth moving on
14:53 hagarth Prevent NFS restart on Volume change
14:53 jclift So, core for this, pending further discussion as well
14:54 rjoseph This one is from me
14:54 jclift (this == on wire compression thing)
14:54 hagarth jclift: right
14:54 * edward1 thought that compression is a business of local file systems
14:54 avati vshankar: let's discuss deeper offline
14:54 hagarth rjoseph: looks like core to me
14:54 jdarcy No-NFS-restart = core?
14:54 sforsythe joined #gluster-dev
14:54 vshankar avati: sure
14:54 rjoseph I think we should take this up in two phases.
14:55 hagarth rjoseph: what are the phases?
14:55 rjoseph Anything which involve a graph change should be taken in second phase
14:55 avati edward1: not every local filesystem developer shares that opinion
14:55 hagarth rjoseph: so the rest would be core for 3.5?
14:55 rjoseph Any changes which does not require a graph change can be taken as core
14:55 hagarth sounds reasonable to me
14:55 VivekAgarwal I would second that
14:55 avati rjoseph: you mean a topology change?
14:56 rjoseph NFS uses single graph for all the volumes therefore it will take lot of work to do graph related changes
14:56 rjoseph yes
14:56 avati yep..
14:56 hagarth ok, phase 1 is core. phase 2 is NtH.
14:56 avati +1 for core for non-topological changes
14:56 hagarth moving on
14:56 hagarth Quota_Scalability
14:56 jdarcy Core.
14:56 hagarth this one is mine, given that we already have ongoing work upstream
14:57 hagarth I am okay with this being Core.
14:57 bfoster shouldn't the existing work be itemized on its own?
14:57 hagarth bfoster: could you elaborate please?
14:58 bfoster i.e., shouldn't we have a "quota" feature? or does this refer to that?
14:58 bfoster for the rework that's happening now
14:59 hagarth bfoster: this refers to that and enhancements to the ongoing rework.
14:59 bfoster ok, n/m
14:59 hagarth ok, core it is then.
14:59 hagarth moving on
14:59 hagarth readdir_ahead
15:00 avati i will finish the review soon..
15:00 hagarth bfoster: is there more planned on your existing upstream patch?
15:00 avati hagarth: i think it is review pending
15:00 bfoster nothing major outside of review, probably requires a rebase at least
15:00 hagarth bfoster: core then?
15:00 bfoster agree
15:01 hagarth ok, core it is then
15:01 hagarth moving on
15:01 hagarth SELinux_Integration
15:01 jdarcy bfoster: It looks like this does *not* include the "inject-into-FUSE" part we'd talked about.
15:01 avati hagarth: core
15:01 hagarth avati: this would be testing work mostly, right?
15:01 bfoster jdarcy: correct, there's no concept of directory caching in the kernel iirc
15:01 avati hagarth: yes
15:02 hagarth avati: ok, core then.
15:02 hagarth moving on
15:02 hagarth thousand-node-glusterd
15:02 avati bfoster: nfs client does.. but it's ugly :(
15:02 hagarth i would love to see 1000 node glusterd, but the work involved might be more.
15:02 bfoster avati: interesting, I'll have to take a look. thanks
15:02 jdarcy hagarth: I'd love to make this core, but - again - can't commit to doing it myself.
15:02 hagarth jdarcy: right, I would park it under NtH
15:03 avati +1 NtH 1000node
15:03 hagarth sounds good, moving on
15:03 hagarth zerofill
15:03 jdarcy Weak vote for core.
15:03 mohankumar__ patch already submitted to gerrit, still its not clear should it be overloaded via write operation or not
15:04 avati mohankumar__: qemu wiring is pending on this patch?
15:04 hagarth mohankumar__: yes, we would have to consider the implications for self-heal and rebalance. Let us start an email discussion over this on ML.
15:04 mohankumar__ jdarcy: it will be nice to have this feature for BD xlator truly supporting SCSI write same
15:04 bharata-rao avati, yes, qemu side can be completed once this is finalized
15:04 jclift Me votes core
15:05 hagarth core from me too
15:05 avati bharata-rao: wht's the use case for this (to undestand importance for core/nth)
15:05 jclift It sounds like most of the work is done, and this is good foundational stuff for future real world usage
15:05 avati is it for qcow2/qed's internal use?
15:05 bharata-rao bharata-rao, creation of zeroed and preallocated vm image with server and/or storage offload
15:05 avati bharata-rao: we already have fallocate for that right?
15:05 mohankumar__ avati: and also scrubbing VM image after deleting the VM
15:06 avati mohankumar__: thanks.. that makes sense
15:06 hagarth yeah, scrubbing would be easier with this.
15:06 bharata-rao avati, space committed on storage
15:06 hagarth core then?
15:06 avati core +1
15:07 hagarth sounds good, we are at the end of the list.
15:07 hagarth I have one more proposal to add here
15:07 ppai joined #gluster-dev
15:07 jclift Heh
15:07 hagarth since we have a libgit xlator prototype available and the feature page was submitted around 3.4 time frame
15:07 hagarth can we consider it as NtH for 3.5?
15:08 jclift Feature page for it?
15:08 avati who was the owner? shishir?
15:08 hagarth avati: yes
15:08 kkeithley was that his versioned file thing?
15:08 avati is he willing to propose it for 3.5? or are you proposing a change of ownership?
15:08 hagarth jclift: will fish that out
15:08 jclift hagarth: k, no objections here then.
15:09 hagarth avati: he is willing
15:09 hagarth http://review.gluster.org/#/c/4843/
15:09 avati hagarth: was the gfid hardlink issue resolved?
15:09 hagarth avati: not very sure
15:09 avati that was a pretty crucial thing for it to be real world usable
15:10 hagarth avati: agree, can we consider this as NtH pending ML discussion?
15:10 jclift No objection to that here
15:10 avati i think so.. let's first convince ourselves that the approach is feasible
15:10 avati i'm ok with NtH/Core after that
15:10 hagarth right
15:10 hagarth ok. we are all done with the features.
15:10 jclift After all, if it turns out to be crap, we can always jettison it :D
15:11 hagarth Coming to 2. Acceptance Criterion
15:11 kkeithley that's optimism for you
15:11 rjoseph hagarth: I have a question related to "Exports and Netgroups Authentication for NFS"
15:11 hagarth since we are running short of time, here's my short take on acceptance.
15:11 rjoseph Isn't it similar to what we have done for subdir AUTH support in 3.4?
15:11 hagarth 1. all significant development to happen on gerrit + forge.gluster.org
15:12 ppai compression xlator would be "Nice to have" feature
15:12 hagarth 2. documentation and regression tests to be added as part of patchset commit.
15:12 hagarth 3. no significant performance regression if feature is disabled.
15:12 avati rjoseph: it is a different way of providing input.. the feature and enforcement is still core to gluster
15:13 hagarth I will follow up with more on ML, but any objections to the 3 criterion?
15:13 rjoseph avati: thanks for clarifying
15:13 * jclift is unsure how to get Multi-Node Test Suite onto gerrit
15:13 jclift But, if it's feasible, no objection
15:13 hagarth jclift: of course, that can be an exception :)
15:13 jclift :)
15:14 hagarth sounds like we have none. Let us continue that discussion on gluster-devel.
15:14 avati +1 for criteria
15:14 kkeithley ditto
15:14 jdarcy hagarth: That implies 2.5: feature must have an enable/disable option.  Are there any cases where that would be burdensome?
15:15 jclift jdarcy: Hmmm, not everything would suit that
15:15 vshankar ppai: is much work left for compression xlator?
15:15 jclift "Better Peer Identification" for example seems "all in"
15:16 avati yeah..
15:16 hagarth jdarcy: most features proposed can be enabled/disabled. If a feature is not, there should be no regression in performance if it replaces an existing piece.
15:16 ppai vshankar: a few bugs and making it pluggable
15:16 jclift hagarth: That's clearer
15:16 hagarth for e.g., bringing in client_t shouldn't cause a perf. hit
15:16 avati better peer identifycation..that patch is going to be bloody ;)b
15:16 jclift avati: :)
15:16 jdarcy Maybe 3: no unavoidable performance impact
15:16 hagarth jdarcy: +1 for that
15:17 hagarth ok, thanks everybody for making to 3.5 planning.
15:17 hagarth let us re-group around the time of code freeze to see where we are.
15:17 hagarth #endmeeting
15:17 vshankar ppai: should be doable, I think :)
15:17 jdarcy October 4?
15:18 hagarth jdarcy: yes
15:18 jclift People, please add yourselves to the "Attendees" list on the etherpad
15:18 jclift hagarth: I'll send out the results in a minute
15:18 jclift To gluster-devel
15:18 hagarth jclift: thank you, much appreciate your help!
15:18 jclift np
15:18 ppai vshankar: yes, hopefully lz4 gets proper streaming by then
15:19 vshankar ppai: we'll concentrate to making it pluggable and zlib being the only plug (for now :P)
15:19 avati ppai: does it support providing read/write handlers for the backend data?
15:20 avati vshankar: yeah, "at least" one plug :)
15:21 ppai vshankar: i'm not sure what that means :P
15:22 vshankar avati: ppai: need to explore more into lz4.
15:24 ppai left #gluster-dev
15:25 jclift ndevos avati rfortier: Should I add you to the attendee list?
15:25 jclift I'm writing up the results email, and including attendees
15:25 jclift (from the etherpad list)
15:25 sforsythe left #gluster-dev
15:26 jclift vshankar: You're not on the attendee list yet are you?
15:26 jclift vshankar: http://titanpad.com/xL7AGRkjVJ
15:27 avati jclift: oops, missed that
15:27 avati just listed myself in the right column
15:28 jclift avati: Thx :)
15:28 vshankar jclift: added myself
15:28 jclift vshankar: Thx :)
15:28 jclift mohankumar__: Do you want to be on the official "attendee" list for the meeting?
15:28 jclift mohankumar__: I'm sending out the results in a few minutes, with the attendee list in it
15:28 mohankumar__ mohankumar__: why not? :)
15:29 jclift http://titanpad.com/xL7AGRkjVJ
15:29 jclift mohankumar__: In that case, add yourself. :)
15:29 jclift mohankumar__: And anyone else I've missed
15:29 jclift Anyone know who "ppai" is?
15:29 jclift He attended, but I'm unsure of name
15:30 jclift Hmmm, it's probably more accurate if I just omit the attendance
15:30 vshankar jclift: Prashanth Pai
15:30 jclift tx
15:31 mohankumar__ jclift: sure, connection lost to etherpad server
15:31 mohankumar__ jclift: for zerofill also mailing list discussion needed
15:32 jclift mohankumar__: Cool.  All good.
15:32 jclift hagarth: Emailed out the results.
15:33 jclift I left off the attendance list, just to not offend anyone I miss ;)
15:33 mohankumar__ okie
15:36 mohankumar__ avati: dumb question, is it ok to use syncops in bd xlator?
15:39 bala joined #gluster-dev
15:44 avati mohankumar__: using syncops inside a synctask_new() procedure is safe anywhere
15:44 mohankumar__ avati: ok
15:52 hagarth joined #gluster-dev
15:58 johnmark GAH. I hate changing time zones :(
15:59 johnmark jclift: hagarth: avati: mohankumar__: nice work, guys
15:59 johnmark great to see all these new names, as well :)
15:59 lalatenduM joined #gluster-dev
16:01 jclift johnmark: :)
16:01 jclift johnmark: Gluster Community Discussion in 1 hr?
16:04 johnmark jclift: no, because I'm on a plane then
16:04 johnmark I thought we had moved to Thursdays? Do you still see a calendar invite for Wednesdays?
16:04 jclift Yeah, today is still in my Calendar
16:04 jclift johnmark: Ahhh, tomorrow's one is there too
16:05 jclift johnmark: It's probably just my iCal not being in sync().  I'll nuke the meeting from iCal.  Ignore it if is emails you. ;)
16:06 johnmark cool, thanks :)
16:21 kkeithley joined #gluster-dev
16:26 kkeithley joined #gluster-dev
16:36 kkeithley joined #gluster-dev
16:37 kshlm joined #gluster-dev
17:27 Technicool joined #gluster-dev
18:00 rfortier joined #gluster-dev
18:03 deepakcs joined #gluster-dev
18:03 deepakcs left #gluster-dev
19:01 edward1 joined #gluster-dev
19:03 lpabon joined #gluster-dev
19:26 lpabon joined #gluster-dev
19:33 rfortier joined #gluster-dev
22:36 asias joined #gluster-dev
22:37 awheele__ joined #gluster-dev
22:46 portante a2_, avati: do you know if client side self heal is off by default in Big Bend?
22:47 portante and is it safe to use the quick-read translator in Big Bend?

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary