Perl 6 - the future is here, just unevenly distributed

IRC log for #gluster-dev, 2014-12-17

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

All times shown according to UTC.

Time Nick Message
00:13 _Bryan_ joined #gluster-dev
01:28 bala joined #gluster-dev
03:35 kanagaraj joined #gluster-dev
04:01 atinmu joined #gluster-dev
04:06 itisravi joined #gluster-dev
04:11 shubhendu joined #gluster-dev
04:28 Gaurav_ joined #gluster-dev
04:30 spandit joined #gluster-dev
04:31 nishanth joined #gluster-dev
04:41 lalatenduM joined #gluster-dev
04:49 atalur joined #gluster-dev
04:51 ppai joined #gluster-dev
04:52 jiffin joined #gluster-dev
04:53 rafi joined #gluster-dev
04:53 Rafi_kc joined #gluster-dev
04:53 ndarshan joined #gluster-dev
04:54 anoopcs joined #gluster-dev
05:05 soumya_ joined #gluster-dev
05:17 prasanth_ joined #gluster-dev
05:25 kdhananjay joined #gluster-dev
05:26 Anuradha joined #gluster-dev
05:37 hagarth spandit: ping, had a question regarding patch 9282
05:37 aravindavk joined #gluster-dev
05:38 spandit hagarth: yeah, tell me
05:38 hagarth spandit: I don't understand the TODO in that patch.
05:39 hagarth with 2-way replication, there can never be a complete consistency guarantee if a brick happens to be down.
05:39 spandit hagarth: As mentioned in the patch, we are skipping the cached value in case of readdirp in snapshot volume
05:39 spandit hagarth: But ideally, that should not be the way to go.
05:39 hagarth in general with n-way replication, if n-1 bricks are down, consistency guarantee is not strict. It is only a loose guarantee.
05:40 spandit hagarth: Currently as we are limited by AFR functionality in readdirp, we thought of modifying in md-cache instead
05:40 hagarth can we nuke the todo from the patch? that seems confusing to me.
05:40 spandit hagarth: Sure, I'll work on that
05:41 hagarth spandit: I don't think it is a limitation, it is as per design. If you need high consistency, you need to ensure that more bricks are online.
05:41 hagarth spandit: the same problem would exist in an activated snapshot, right?
05:42 spandit hagarth: you mean mounted snap volume, or USS ?
05:42 hagarth mounted snap volume
05:42 spandit yeah, it does
05:42 hagarth OK, how do we plan to fix that? :)
05:43 Gaurav__ joined #gluster-dev
05:43 spandit We need to make sure that we propogate the readdirp call till AFR, instead of getting a cached value from md-cache
05:43 spandit only the readdirp request
05:45 hagarth that would affect performance in the normal case. we should only do that if afr doesn't have quorum.
05:47 spandit Hmmm, after the quorum is met we anyways get the right set of data, I think you are right. But, will it not effect the performance if we check whether quorum is met everytime ?
05:48 hagarth spandit: quorum lost/gained notifications can be asynchronous
05:49 hagarth basically a notify from afr can intimate higher translators about these events and the upper xlators can act accordingly
05:49 spandit Alright, that sounds fine. I'll work on that. Thanks :)
05:50 hagarth spandit: cool, thanks! :)
05:52 overclk joined #gluster-dev
05:55 soumya_ joined #gluster-dev
06:03 spandit hagarth: The bug description is like this: "self-heal-daemon" was turned off intentionally and made the bricks are made inconsistent and now the snapshot was taken
06:04 spandit hagarth: After that brick is brought back up. Now, even if we check the quorum we might end up in the same situation. I know, this is not a supported case.
06:04 spandit hagarth: Am not sure how to go ahead with this, apart from disabling caching in md-cache
06:05 raghu joined #gluster-dev
06:06 kshlm joined #gluster-dev
06:06 spandit hagarth: Diabling caching in md-cache for readdirp operation in snapshot volume
06:08 hagarth spandit: this can happen with regular volumes too
06:08 rjoseph joined #gluster-dev
06:20 hagarth spandit: disabling md-cache for now should be ok but let us make the comment a little more accurate
06:23 rjoseph hagarth: how is quorum check going to help in this case?
06:24 rjoseph the problem here is the one of the brick has latest data and the other brick did not got the update.
06:25 rjoseph If lookup reaches AFR, it marks the correct copy and always reads the correct copy
06:27 rjoseph Here in the bug it seems md-cache cached the information from the wrong brick
06:35 Gaurav__ joined #gluster-dev
06:39 hagarth rjoseph:  Even if this is fixed for USS, the same problem would be present for normal clients/fuse mounted activated snapshots. I am not in favor of rushing this fix in.
06:40 rjoseph I think the problem would be there for USS not much for fuse mounted snapshots
06:41 rjoseph Fuse mounted snapshots and actual volume has same behaviour
06:41 rjoseph In main volume the problem is not seen frequently because of the md-cache timeout
06:42 rjoseph Which I don't  think is there when we use gfapi. I can cross check this but this seems to be the problem
06:43 spandit rjoseph: md-cache timeout is there even for USS, which behaves same as normal volume
06:43 hagarth rjoseph: md-cache timeout should be active in gfapi volumes too. md-cache would be deployment agnostic.
06:45 rjoseph spandit: oh ok... I thought the cache timeout is only seen in main volume but not in USS. Can you please check with vijai once?
06:46 spandit rjoseph: Sure.
06:47 raghu md-cache timeout is there in all the places, USS initiated gfapi instance, mounted activated snapshot, and fuse mounted regular volume
06:51 bala joined #gluster-dev
06:54 ppai joined #gluster-dev
06:56 kdhananjay joined #gluster-dev
07:03 shubhendu joined #gluster-dev
07:16 pcaruana joined #gluster-dev
07:35 ndarshan joined #gluster-dev
07:38 rgustafs joined #gluster-dev
07:39 rgustafs joined #gluster-dev
07:40 badone joined #gluster-dev
07:41 shubhendu joined #gluster-dev
07:53 ndarshan joined #gluster-dev
08:42 bala joined #gluster-dev
09:03 Debloper joined #gluster-dev
09:03 ndarshan joined #gluster-dev
09:15 ppai joined #gluster-dev
09:21 bala joined #gluster-dev
09:53 bala joined #gluster-dev
10:14 lalatenduM ndevos, are you around ?
10:20 rgustafs joined #gluster-dev
10:21 ndevos lalatenduM: yes, I am :)
10:22 * ndevos just fixed the internet by rebooting his router
10:27 hagarth ndevos++
10:27 glusterbot hagarth: ndevos's karma is now 69
10:29 lalatenduM ndevos, pm
10:29 ndevos lalatenduM: oh, thanks!
10:53 nishanth joined #gluster-dev
11:49 ppai joined #gluster-dev
11:55 nishanth joined #gluster-dev
11:55 ndevos hmm, my bricks are running out of file descriptors... could that be an issue with glfs_h_*() functions?
11:56 ndevos soumya_: do you know without looking at the sources how/if gfls_h_*() keeps and fd open on the bricks?
12:00 lpabon joined #gluster-dev
12:03 jdarcy joined #gluster-dev
12:07 kanagaraj joined #gluster-dev
12:18 soumya_ ndevos, hey sorry..was not at my desk
12:18 ndevos soumya_: no problem, you're attending the community meeting, RIGHT?
12:19 soumya_ ndevos, yes..just joined
12:19 ndevos soumya_: hehe :)
12:20 ndevos soumya_: I suspect that nfs-ganesha holds on to FDs and those are kept open on the bricks, could that be right?
12:20 krishnan_p joined #gluster-dev
12:20 krishnan_p xavih, hi
12:21 ndevos soumya_: I can see that the brick processes run out of file descriptors, that gets an error in gfapi and nfs-ganesha throws fatal errors after that :-/
12:22 soumya_ ndevos, interesting..but ganesha does close files via glfs_close(..) which ideally should flush the fd on bricks
12:23 ndevos soumya_: hmm, so a glfs_h_write(....) would close the FD when done? think in NFSv3 (no open/close) here, please :)
12:24 xavih krishnan_p: hi
12:24 krishnan_p xavih, regarding our discussion on Coverity's assignment of taint to data, what did you mean by 'safe' in your recent response?
12:25 soumya_ ndevos, even for v3 read/writes, we do cache_inode_open/close which internally calls glfs_open/close...
12:25 soumya_ but these are under certain checks..
12:25 soumya_ maybe we could be missing out close anytime..
12:26 xavih krishnan_p: I think the problem is that there's a pointer marked as tainted, and that pointer is used to access the memory accounting info stored just before the address pointed by the pointer
12:26 ndevos soumya_: oh, okay, I think I need to look into that then...
12:26 xavih krishnan_p: this means that coverity considers all data read as tainted. This includes the 'type' that is later used to index an array
12:27 soumya_ ndevos, yeah..I am aware that we currently do not purge inodes properly ...
12:27 krishnan_p xavih, the pointer under question is a fixed size buffer placed in the stack. Wouldn't that suffice to call it un-tainted?
12:28 ndevos soumya_: oh, okay, I think that causes some of the test runs I do to fail... we need to fix that
12:28 xavih krishnan_p: fgets' buffer gets tainted because it contains untrusted data
12:28 xavih krishnan_p: it seems that coverity propagates the tainted flag when pointers are used
12:29 xavih krishnan_p: for example, if you copy 'buffer' into another pointer, that new pointer also gets tainted
12:29 krishnan_p xavih, yes. It does. I walked that part in the coverity tiool
12:29 xavih krishnan_p: and it seems that this ends with 'type' being tainted
12:29 krishnan_p xavih, your analysis is in line with waht the coverity UI points out
12:29 soumya_ ndevos, oh..right.. inode->ref and inode->lookup count never reaches zero
12:30 krishnan_p xavih, the real question is how do we teach coverity, under certain conditions, that the data is not tainted as it concludes.
12:30 soumya_ ndevos, even when the file is close and ganesha does handle_release..we definitely need to fix that
12:31 soumya_ ndevos, and thinking about that, it sounds highly likely we have similar issues with fd count as well
12:31 xavih krishnan_p: I don't know that :P. Sorry. Maybe I misinterpreted your question when you asked for a programmatically way to avoid the error...
12:31 krishnan_p xavih, it also means that I wasn't being precise ;) No problem.
12:33 ndevos soumya_: oh, yeah, I remember something about that... I guess I'll do some systemtapping in gfapi and see whats up
12:35 ira joined #gluster-dev
12:38 soumya_ ndevos, sure thanks :) ... I shall check the code too
12:48 edward1 joined #gluster-dev
12:50 ira joined #gluster-dev
12:51 lalatenduM kkeithley, check http://lists.centos.org/pipermail/centos-promo/2014-December/001492.html
12:51 kanagaraj joined #gluster-dev
12:52 lalatenduM kkeithley, I had a discussion with ndevos on this and have proposed something
12:52 lalatenduM kkeithley, between you me and ndevos we should be able to do it , any thoughts?
12:54 kkeithley lalatenduM: I saw your proposal for the tutorial. Yes, we should be able to do something
12:54 lalatenduM kkeithley, yeah
12:55 kkeithley we should check with johnmark. We had a hackathon at Summit back in June. Maybe slightly along those lines, but more tutorial
12:55 kkeithley s/We/He/
12:55 lalatenduM kkeithley, sure we can do that
13:11 lalatenduM joined #gluster-dev
13:11 anoopcs joined #gluster-dev
13:16 ndevos lalatenduM: oh, maybe we can gte purpleidea to show puppet-gluster too?
13:16 ndevos s/gte/get/
13:17 lalatenduM ndevos, yeah, purpleidea  are you coming to fosdem?
13:20 purpleidea lalatenduM: cc ndevos yeah i think i might be... definitely config camp, and i'll be in czech republic before for devconf... so yeah, i could do fosdem i think
13:20 purpleidea what day in particular?
13:20 lalatenduM purpleidea, check this out http://lists.centos.org/pipermail/centos-promo/2014-December/001504.html
13:21 purpleidea lalatenduM: yeah, saw that
13:22 lalatenduM purpleidea, you are the guy for puppet-gluster :)
13:22 purpleidea lalatenduM: i could train you... :)
13:23 * ndevos actually wants to try out ansible...
13:23 * gothos likes salt very much
13:24 lalatenduM hagarth, do you want to add something here http://lists.centos.org/pipermail/centos-promo/2014-December/001504.html , we can coordinate between gluster community folks for this. ndevos and kkeithley  is interested  too
13:24 lalatenduM purpleidea, sure no prob :), but nothing like learning from the master itself :)
13:25 lalatenduM gothos, have tried salt for gluster deployment ?
13:25 lalatenduM s/have/have you/
13:26 gothos lalatenduM: well, we're installing our servers via fai, which configures the gluster repo for centos and installs the gluster client and sets the mount point
13:26 gothos we still have to set the network stuff ourselves tho
13:26 gothos after that salt does that again or rather checks that everything is okay, eg fstab is corrent and gluster-fuse is installed
13:27 ndevos gothos: hmm, salt uses an agent? thats something I try not to need..
13:27 gothos ndevos: yes, it does. but I honestly don't mind
13:27 lalatenduM gothos, cool
13:27 hchiramm joined #gluster-dev
13:28 purpleidea ndevos: cc gothos actually all the config management solutions suck, except puppet has been the one that is closest to what i think is "correct" and the one that I can manipulate to do what i want. ansible isn't config management, despite what they tell you ;)
13:28 gothos and apparently ansible is rather slow, which might be an issue with big installations, but we never tried that
13:28 purpleidea it's really an idempotent orchestrator
13:28 * ndevos just installs very minimal systems, and then throws them away when whatever bug is fixed
13:28 purpleidea and ansible has defective by design issues too
13:29 gothos purpleidea: yeah, the thing is that puppet is like the death start and we only really need a laser pointer ;)
13:29 ndevos purpleidea: I just need something that installs systems for me, and that makes it easy for me to run some commands
13:29 gothos we only have around 20 server at my current job
13:29 purpleidea gothos: hehe death star, lol
13:29 ndevos I think Puppet is too advanced for my purpose, and its written in a language I dont (want to) understand
13:30 purpleidea ndevos: gothos: yeah, i mean a lot of people use different tools... if you never scale things and never have more than a few servers, fine, but things always get complicated :(
13:31 gothos purpleidea: well, we wont be able to expand physically and this is only a research institute. so stuff isn't going to change anytime soon
13:31 ndevos purpleidea: yeah, for real enterprise deployments puppet certainly makes sense
13:31 ndevos I'm doing installations over PXE/kickstart, and configure things manually, that works too and does not take too much of my time
13:31 gothos and our server room is already rather full and on the 15. floor ;)
13:31 purpleidea ndevos: the real take away point i want to make, is it's not your fault that puppet is complicated in a lot of ways. that's a puppet failure, and eventually someone will build a next gen thing to fix that issue
13:32 purpleidea gothos: as a side note, if you're looking at writing a salt module for glusterfs, a bunch of the techniques (and some code) in puppet-gluster would probably be useful for you
13:32 ndevos purpleidea: indeed, its too complicated for me to try and run with it in ~30 minutes
13:33 purpleidea lalatenduM: did you want me to email the centosdev@centos.org as shown here: http://www.eventbrite.co.uk/e/centos-dojo-brussels-belgium-jan-30th-2015-tickets-14956180338 or is it less formal?
13:33 gothos purpleidea: k, but I doubt it, at least I would know what we would need that for of the top of my hat
13:33 purpleidea gothos: sorry did understand that last sentence, can you rephrase?
13:35 gothos purpleidea: I don't think I'll create/need anything like that, don't know what we would need that for. (a salt gluster module)
13:35 gothos I'm much more interested in better nagios monitoring for gluster
13:36 hagarth lalatenduM: If I am around there, happy to do a glusterfs next talk.
13:36 lalatenduM purpleidea, you want to send a mail for? if you talking abt the the gluster session in the dojo than my mail should do for the formal proposal
13:37 lalatenduM hagarth, cool
13:37 lalatenduM purpleidea, I meant http://lists.centos.org/pipermail/centos-promo/2014-December/001504.html
13:37 hagarth hchiramm: we seem to have a problem with the blogs now
13:38 hagarth twitter's talking about a new post on Bannerghatta National Park!
13:38 purpleidea lalatenduM: okay, i won't send anything, but i'll aim to be there on jan30th, correct?
13:39 hagarth hchiramm: that is coming from rjoseph's blog syndication
13:40 hagarth gothos: have you seen gluster-nagios - http://gluster.org/pipermail/gluster-users.old/2014-June/017819.html
13:41 lalatenduM purpleidea, yeah , between us we can plan the session . however I will suggest you to register for the event. seats are limited I think
13:42 purpleidea lalatenduM: okay, done
13:43 gothos hagarth: nope, I'll take a look :)
13:45 hagarth hchiramm: have cleaned up the non gluster posts on facebook & twitter :)
13:49 vimal joined #gluster-dev
13:54 vimal joined #gluster-dev
14:04 prasanth_ joined #gluster-dev
14:27 raghu joined #gluster-dev
14:38 shubhendu joined #gluster-dev
14:39 jdarcy joined #gluster-dev
14:59 kkeithley aw, I liked the tigers in the Bannerghatta N.P. ;-)
15:00 kkeithley JustinClift: dlambrig needs a jenkins account. Can you help him with that?
15:02 kkeithley or maybe I can do that. Let me check
15:02 wushudoin joined #gluster-dev
15:04 wushudoin joined #gluster-dev
15:07 lalatenduM joined #gluster-dev
15:22 kkeithley someone already created your jenkins account yesterday
15:26 ndevos kkeithley: is that a normal user account on build.gluster.org? I think I changed my passwd there once, and that changed it in Jenkins too
15:27 tdasilva joined #gluster-dev
15:27 ndevos and ssh on build.g.o only allows ssh-keys, so that got me confused for a while :)
15:29 kkeithley hmmm. okay.  I've put his id_rsa.pub in his user account, but he's getting permission denied when he tries to ssh
15:30 kkeithley in his ~/.ssh/authorized_keys2 file
15:31 kkeithley oops,
15:32 lalatenduM joined #gluster-dev
15:38 shyam joined #gluster-dev
15:40 soumya_ joined #gluster-dev
15:45 dlambrig I'm in, thanks guys.
15:50 jobewan joined #gluster-dev
15:59 ira joined #gluster-dev
16:06 shyam joined #gluster-dev
16:29 JustinClift kkeithley: Good you got it sorted.
16:29 kkeithley yup
16:29 JustinClift ndevos: Yeah, jenkins auth's using the build.g.o user logins
16:30 kkeithley I barely remember yesterday. Let alone things I did three years ago. ;-)
16:33 JustinClift :)
16:33 JustinClift k, I'm outta here til mid-Jan.  Happy Xmas / NYE / etc everyone. :D
16:37 kkeithley And Festivus for the Rest of Us
16:37 kkeithley See you in the new year
16:44 vimal joined #gluster-dev
16:47 jobewan joined #gluster-dev
16:54 hagarth hmm, my email server seems to be in a holiday mood too
18:15 Humble hagarth, still there
18:15 Humble missed ur ping..
18:15 Humble yeah. I had syndicated rajesh's blog.
18:16 Humble it is sad that it took , other articles as well
18:17 Humble I acked the default options.
18:18 Humble not sure which option caused it.
18:18 Humble hagarth++ thanks !!!
18:18 glusterbot Humble: hagarth's karma is now 29
18:27 anoopcs joined #gluster-dev
19:04 hagarth joined #gluster-dev
20:34 dlambrig left #gluster-dev
22:20 badone joined #gluster-dev

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