#ceph IRC Log


IRC Log for 2012-09-05

Timestamps are in GMT/BST.

[0:14] * dspano (~dspano@rrcs-24-103-221-202.nys.biz.rr.com) Quit (Quit: Leaving)
[0:15] * aliguori (~anthony@ Quit (Remote host closed the connection)
[0:25] * elder (~elder@c-71-195-31-37.hsd1.mn.comcast.net) Quit (Remote host closed the connection)
[0:26] * JT (~john@astound-64-85-239-164.ca.astound.net) has joined #ceph
[0:26] <JT> Does anyone have any tips for running Ceph with Valgrind?
[0:28] <gregaf> use a fast machine :p
[0:28] <gregaf> what are you after?
[0:29] <JT> Something meatier than simply starting the cluster wtih "--valgrind" ... then log messages go to stderr? Check some console? Etc?
[0:31] <gregaf> oh, you're trying to run the whole cluster under valgrind?
[0:32] <JT> Or a particular daemon... that's what I mean... if it makes more sense to just run some OSDs, but not monitors, mds, or radosgw, that's the kind of guidance I'm looking for...
[0:34] * elder (~elder@c-71-195-31-37.hsd1.mn.comcast.net) has joined #ceph
[0:34] <gregaf> depends on what information you're trying to extract
[0:36] <gregaf> (it's been a while since I used this; refreshing my memory)
[0:37] <JT> Yes, it mentions threading issues, memory errors, profile...
[0:37] <JT> Would anyone use this outside of the context of teuthology?
[0:37] <gregaf> the --valgrind option just prepends the normal commands with "valgrind ", so Ceph's logging and such will go in the normal places
[0:38] <gregaf> and valgrind itself dumps to stderr
[0:38] <gregaf> but yeah, I don't think anybody should be using it outside of automated test suites
[0:38] <JT> ok...
[0:39] <elder> Two machine hangs today. I am afraid for my computer's safety if it happens again.
[0:41] * andreask (~andreas@chello062178013131.5.11.vie.surfer.at) Quit (Quit: Leaving.)
[0:45] * Cube (~Adium@cpe-76-95-223-199.socal.res.rr.com) has joined #ceph
[1:03] * amatter_ (~amatter@ has joined #ceph
[1:08] * amatter (~amatter@ Quit (Ping timeout: 480 seconds)
[1:08] * yoshi (~yoshi@p28146-ipngn1701marunouchi.tokyo.ocn.ne.jp) has joined #ceph
[1:23] * danieagle (~Daniel@ Quit (Quit: Inte+ :-) e Muito Obrigado Por Tudo!!! ^^)
[1:26] * pentabular (~sean@adsl-71-141-232-252.dsl.snfc21.pacbell.net) has joined #ceph
[1:26] * amatter (~amatter@ has joined #ceph
[1:30] * amatter_ (~amatter@ Quit (Ping timeout: 480 seconds)
[1:31] * BManojlovic (~steki@ Quit (Remote host closed the connection)
[1:40] * Leseb (~Leseb@5ED01FAC.cm-7-1a.dynamic.ziggo.nl) Quit (Quit: Leseb)
[1:48] * Tv_ (~tv@2607:f298:a:607:51e0:e578:bd15:6681) Quit (Quit: Tv_)
[1:49] <joao> so, does anyone know by what kind of sorcery is the 'task' method called on a teuthology run?
[1:53] <gregaf> joao: I don't know it that well, but it's part of the teuthology framework pieces — you shouldn't need to worry about it much
[1:53] <gregaf> what are you after?
[1:55] <joao> gregaf, trying to figure out the scope of the functions/methods in the my task file
[1:56] <joao> not that it is relevant for what I'm doing (I think)
[1:56] <gregaf> have you been through some of the other tasks?
[1:56] <gregaf> radosbench.py is a pretty simple one that contains pretty much the bare minimum
[1:56] <joao> yeah
[1:56] <joao> I've been getting inspiration on most tasks, especially on mon_recovery.py ;)
[1:58] <joao> but the "what, where and how is the 'task' method called?" has been popping in my mind quite a lot
[1:58] <dmick> I believe teuthlogy/run_tasks.py is a good starting bit
[1:58] <gregaf> joshd could talk about it more
[1:58] <gregaf> oh, or dmick apparently
[1:59] <gregaf> "task" is just declared-special by our framework; I think it just grabs each task file based on what's in its config and then calls the task method on each of those objects
[2:01] <dmick> yeah, but the directory name is relevant to how it finds them. 'teuthology.task' is a package name
[2:02] <joao> yeah, I was just looking at some odd import hinting just that
[2:02] <joao> from .task import interactive
[2:02] <joao> a big wtf just crossed my mind
[2:03] * adjohn (~adjohn@108-225-130-229.lightspeed.sntcca.sbcglobal.net) Quit (Quit: adjohn)
[2:03] <joao> and I just realized how much I've been underestimating python, and overestimating my comprehension of programming languages
[2:04] <gregaf> dynamic languages: why can't they have a good static interpreter :(
[2:04] <dmick> import just assembles scope dynamically :)
[2:05] <gregaf> Python's packaging is all dictated by the filesystem hierarchy, right?
[2:05] <joao> much like Java's?
[2:05] <dmick> basically. there are search paths but the dotted things correspond to paths
[2:06] <dmick> and leading dots can be magical
[2:06] <gregaf> I'm pretty sure that's just convention in Java — don't you explicitly set the packages within each file? (or maybe it's a mix of convention and required; I'm not sure how well it does at searching outside the localdir)
[2:06] <joao> I thought the dotted things referred to accessing methods within classes
[2:06] <dmick> well yes, outside import
[2:06] <mikeryan> gregaf: jars just contain .class files arranged per their named hierarchy
[2:07] <mikeryan> you can explicitly set jars, but that's akin to setting an LD_PRELOAD
[2:07] <joao> dmick, ah! okay, must have misinterpreted what you said ;)
[2:07] <dmick> . does different things in different contexts
[2:08] <mikeryan> ah misread your comment
[2:08] <mikeryan> you explicitly set the package, but if you set it to something other than the path to the class, it won't import
[2:08] * amatter (~amatter@ Quit (Ping timeout: 480 seconds)
[2:09] <joao> dmick, yeah, got it
[2:09] <joao> so 'from .task import bla' means it will import bla, assuming it will find it under ./task
[2:10] <dmick> yes, although I think ".task => ./task" is slightly more complex
[2:14] <dmick> .task actually means "relative to the package containing the import statement" rather than "the current dir". A slight modification, but relevant. It explictily avoids the search path, I believe
[2:15] <dmick> '..name' is "up one package level", etc.
[2:15] <dmick> http://www.python.org/dev/peps/pep-0328/
[2:16] <joao> thanks for clarifying :)
[2:16] <joao> and thanks for the link
[2:37] <elder> sagewk those two patches are pushed to testing now.
[2:39] * JT (~john@astound-64-85-239-164.ca.astound.net) Quit (Ping timeout: 480 seconds)
[2:42] * amatter (~amatter@c-174-52-137-136.hsd1.ut.comcast.net) has joined #ceph
[2:48] * JT (~john@astound-64-85-239-164.ca.astound.net) has joined #ceph
[2:52] * nhmhome (~nh@67-220-20-222.usiwireless.com) has joined #ceph
[2:52] * nhm (~nh@67-220-20-222.usiwireless.com) has joined #ceph
[2:58] * amatter (~amatter@c-174-52-137-136.hsd1.ut.comcast.net) Quit (Ping timeout: 480 seconds)
[3:26] * pentabular (~sean@adsl-71-141-232-252.dsl.snfc21.pacbell.net) Quit (Remote host closed the connection)
[4:01] * renzhi (~renzhi@ has joined #ceph
[4:06] * chutzpah (~chutz@ Quit (Quit: Leaving)
[4:15] * amatter (~amatter@c-174-52-137-136.hsd1.ut.comcast.net) has joined #ceph
[4:21] * lxo (~aoliva@lxo.user.oftc.net) Quit (Remote host closed the connection)
[4:30] * amatter_ (~amatter@ has joined #ceph
[4:34] * lxo (~aoliva@lxo.user.oftc.net) has joined #ceph
[4:35] * amatter (~amatter@c-174-52-137-136.hsd1.ut.comcast.net) Quit (Ping timeout: 480 seconds)
[4:43] * maelfius (~mdrnstm@ Quit (Quit: Leaving.)
[5:12] * joshd (~joshd@2607:f298:a:607:221:70ff:fe33:3fe3) Quit (Quit: Leaving.)
[5:28] * amatter_ (~amatter@ Quit (Ping timeout: 480 seconds)
[5:32] * loicd (~loic@magenta.dachary.org) Quit (Quit: Leaving.)
[5:32] * loicd (~loic@magenta.dachary.org) has joined #ceph
[6:01] * maelfius (~mdrnstm@pool-71-160-33-115.lsanca.fios.verizon.net) has joined #ceph
[6:13] * amatter (~amatter@c-174-52-137-136.hsd1.ut.comcast.net) has joined #ceph
[6:24] * kibbu (claudio@owned.ethz.ch) Quit (Ping timeout: 480 seconds)
[6:39] * amatter_ (~amatter@ has joined #ceph
[6:39] * Ryan_Lane (~Adium@154.sub-166-250-37.myvzw.com) Quit (Ping timeout: 480 seconds)
[6:44] * amatter (~amatter@c-174-52-137-136.hsd1.ut.comcast.net) Quit (Ping timeout: 480 seconds)
[7:28] * nhm (~nh@67-220-20-222.usiwireless.com) Quit (Ping timeout: 480 seconds)
[7:29] * nhm_ (~nh@67-220-20-222.usiwireless.com) has joined #ceph
[7:30] * maelfius (~mdrnstm@pool-71-160-33-115.lsanca.fios.verizon.net) Quit (Quit: Leaving.)
[7:32] * nhm (~nh@67-220-20-222.usiwireless.com) has joined #ceph
[7:32] * Kermin (ca037809@ircip3.mibbit.com) has joined #ceph
[7:32] * nhm_ (~nh@67-220-20-222.usiwireless.com) Quit (Read error: Connection reset by peer)
[7:32] <Kermin> Hi all
[7:33] <Kermin> Can you please tell me what is the port number which is used while data transfer occurs in between osds ( replication factor = 3)
[7:33] <Kermin> ?
[7:38] * kibbu (claudio@owned.ethz.ch) has joined #ceph
[7:56] * coredumb (~coredumb@ns.coredumb.net) Quit (Ping timeout: 480 seconds)
[8:02] * coredumb (~coredumb@ns.coredumb.net) has joined #ceph
[8:12] <Kermin> Hi all
[8:12] <Kermin> Can you please tell me what is the port number which is used while data transfer occurs in between osds ( replication factor = 3)
[8:29] * Ryan_Lane (~Adium@ has joined #ceph
[8:41] * andret (~andre@pcandre.nine.ch) Quit (Remote host closed the connection)
[8:42] * loicd (~loic@magenta.dachary.org) Quit (Quit: Leaving.)
[8:59] * BManojlovic (~steki@ has joined #ceph
[9:07] * andret (~andre@pcandre.nine.ch) has joined #ceph
[9:12] * EmilienM (~EmilienM@ADijon-654-1-107-27.w90-39.abo.wanadoo.fr) has joined #ceph
[9:25] * andret (~andre@pcandre.nine.ch) Quit (Quit: Verlassend)
[9:30] * andret (~andre@pcandre.nine.ch) has joined #ceph
[9:32] * Ryan_Lane (~Adium@ Quit (Read error: Operation timed out)
[9:40] * loicd (~loic@ has joined #ceph
[9:42] * Leseb (~Leseb@ has joined #ceph
[9:55] * andreask (~andreas@chello062178013131.5.11.vie.surfer.at) has joined #ceph
[9:55] * lxo (~aoliva@lxo.user.oftc.net) Quit (Ping timeout: 480 seconds)
[10:01] * lxo (~aoliva@lxo.user.oftc.net) has joined #ceph
[10:12] <Kermin> hello guys
[10:12] <Kermin> :)
[10:13] <Kermin> I guess many of you are resting now...
[10:13] <Kermin> GN
[10:19] * Kermin (ca037809@ircip3.mibbit.com) Quit (Quit: http://www.mibbit.com ajax IRC Client)
[10:40] * loicd (~loic@ Quit (Quit: Leaving.)
[10:51] * loicd (~loic@ has joined #ceph
[11:02] * loicd (~loic@ Quit (Quit: Leaving.)
[11:13] * yoshi (~yoshi@p28146-ipngn1701marunouchi.tokyo.ocn.ne.jp) Quit (Remote host closed the connection)
[11:19] * tnt (~tnt@212-166-48-236.win.be) has joined #ceph
[11:20] * loicd (~loic@ has joined #ceph
[11:38] * loicd (~loic@ Quit (Quit: Leaving.)
[11:38] * loicd (~loic@ has joined #ceph
[12:08] * loicd (~loic@ Quit (Quit: Leaving.)
[12:08] * loicd (~loic@ has joined #ceph
[13:08] * renzhi (~renzhi@ Quit (Quit: Leaving)
[14:03] * mtk (~mtk@ool-44c35bb4.dyn.optonline.net) Quit (Remote host closed the connection)
[14:08] * hziSot (~ra@ Quit (Read error: Connection reset by peer)
[14:09] * mtk (~mtk@ool-44c35bb4.dyn.optonline.net) has joined #ceph
[14:12] * JT (~john@astound-64-85-239-164.ca.astound.net) Quit (Ping timeout: 480 seconds)
[14:22] * JT (~john@astound-64-85-239-164.ca.astound.net) has joined #ceph
[14:45] * aliguori (~anthony@cpe-70-123-140-180.austin.res.rr.com) has joined #ceph
[15:07] <elder> Wow
[15:07] <elder> I get shell path name completion for files on a remote host.
[15:09] * nhorman (~nhorman@hmsreliant.think-freely.org) has joined #ceph
[15:10] <tnt> elder: yeah, I hate that stuff ...
[15:11] <elder> I discovered it by accident. Fortunately it didn't take very long to resolve.
[15:13] <tnt> Ubuntu also has things like make target autocompletion ... if you happen to tap 'TAB' behing a make when in a complex tree (like webkit or kernel), you're stuck waiting for a minute waiting for it to resolve the autocomplete.
[15:36] * dspano (~dspano@rrcs-24-103-221-202.nys.biz.rr.com) has joined #ceph
[15:52] * iggy (~iggy@theiggy.com) Quit (Remote host closed the connection)
[15:55] <tnt> Can I run GFS2 over RBD ?
[15:55] <tnt> I'm pretty sure I read something about it, but can't remember where and if it was OK or not ..
[15:57] * steki-BLAH (~steki@ has joined #ceph
[15:59] * BManojlovic (~steki@ Quit (Ping timeout: 480 seconds)
[16:16] <tnt> Does anyone know what cephx rights are required for rbd ? [mon] allow r [osd] allow rwx doesn't seem to be enough ?
[16:27] <tnt> nm ...
[16:31] <dspano> If you feel like being brave like myself, cephfs works awesome for me so far in 12.04. Although, I'm not using it for anything particularly heavy.
[16:34] <dspano> Not to say you're not brave. Actually, slightly crazy like myself is probably better.
[16:34] <tnt> Well ... It won't be heavy, I just want a way to share the config files for VMs ... all VM disks are on RBD and the bulk of the data is in RADOSGW.
[16:37] <dspano> I was going to use GFS2 also, but this Ubuntu bug (https://bugs.launchpad.net/bugs/1020207) forced me to reconsider ceph. I'm glad it did.
[16:38] <dspano> Personally, I haven't had any problem hosting my config files for openstack between two cloud controllers via cephfs. I've been running it for about a month or so now. However, most people may consider me crazy for doing so.
[16:39] <dspano> I figured if some of the people running bigger clusters could get away with, so could I :)
[16:40] <tnt> Hehe, well it's just the config files, worst case I can fallback to NFS from the NAS.
[16:41] <tnt> Anybody here tried to use keyctl to add ceph secret to the user keyring rather than using secret=xxx when attaching a rbd ?
[16:44] <tnt> Ah, using 'padd' it works. Need to provide the key in binary rather than base64
[16:46] <tnt> Now if only mon addresses could be discrovered by multicast :p
[16:47] * daniellek (d586a262@ircip2.mibbit.com) has joined #ceph
[16:48] * daniellek (d586a262@ircip2.mibbit.com) Quit ()
[17:11] * steki-BLAH (~steki@ Quit (Quit: Ja odoh a vi sta 'ocete...)
[17:18] * amatter_ (~amatter@ Quit (Ping timeout: 480 seconds)
[17:35] * tnt (~tnt@212-166-48-236.win.be) Quit (Read error: Operation timed out)
[17:38] * Tv_ (~tv@2607:f298:a:607:51e0:e578:bd15:6681) has joined #ceph
[17:38] * brambles (xymox@grip.espace-win.org) Quit (Quit: leaving)
[17:39] * brambles (xymox@grip.espace-win.org) has joined #ceph
[17:47] * amatter (~amatter@ has joined #ceph
[18:03] * andreask (~andreas@chello062178013131.5.11.vie.surfer.at) Quit (Quit: Leaving.)
[18:03] * joshd (~joshd@2607:f298:a:607:221:70ff:fe33:3fe3) has joined #ceph
[18:06] * tnt (~tnt@19.110-67-87.adsl-dyn.isp.belgacom.be) has joined #ceph
[18:20] * maelfius (~mdrnstm@pool-71-160-33-115.lsanca.fios.verizon.net) has joined #ceph
[18:31] * whysyn (c7491c4b@ircip2.mibbit.com) has joined #ceph
[18:33] * Leseb (~Leseb@ Quit (Quit: Leseb)
[18:33] <whysyn> hi guys, anybody who can help me out with a config question?
[18:33] <tnt> ask ... don't ask to ask.
[18:34] <tnt> beware that this is IRC ... latency might be several hours.
[18:34] <whysyn> can i configure a single daemon to bind to multiple ip addresses? i'd prefer this over using LACP
[18:34] <gregaf> people are here now, what's up
[18:35] <gregaf> you want a single daemon to natively use multiple ethernet ports?
[18:35] <gregaf> that's not anything that's implemented right now, sorry
[18:35] <whysyn> for example, three nics in each mon and osd, hopped to three separate switches for redundancy
[18:36] <whysyn> so i will need to use link agg and failover, plus cross connect switches to get improved throughput & fault tolerance?
[18:37] <tnt> Mmm, actually if you start 3 mon process on the same machine each with one of the IP range ...
[18:37] * loicd (~loic@ Quit (Ping timeout: 480 seconds)
[18:37] <gregaf> ewww
[18:38] <gregaf> whysyn: yep, sounds good
[18:38] <tnt> AFAIK the OSD listen on all interfaces / IP and are contacted by IP using whatever IP the mon 'sees'.
[18:38] <whysyn> kk, that's the only bump in the road i've had so far
[18:38] <gregaf> the OSDs can use separate networks for their internal (replication) traffic and for talking to clients, but that's the only multi-NIC capability the system has right now
[18:38] <whysyn> thanks guys
[18:38] <tnt> gregaf: oh really they can do that ? I didn't even know ... what's the name of the config for this ?
[18:39] <gregaf> that's the cluster_addr and public_addr thing
[18:39] * maelfius (~mdrnstm@pool-71-160-33-115.lsanca.fios.verizon.net) Quit (Quit: Leaving.)
[18:39] <tnt> Ah yes, I remember now.
[18:39] <gregaf> thought you would ;)
[18:40] <tnt> whysyn: there is also the so called 'multi path tcp' which might work transparently with ceph.
[18:42] <whysyn> i'll have to dig into that one... relatively new, i assume?
[18:42] <tnt> more like experimental I think :)
[18:42] <tnt> I don't think it's merged in the kernel yet.
[18:45] <tnt> Just tested live migration of Xen VMs using RBD as backend, seems to work nicely.
[18:47] <whysyn> how is the storage performance for your VMs? i'm working on this for a vSphere implementation myself
[18:48] <tnt> Not good
[18:48] <tnt> Somehow the perf inside the domU is halfed compared to the perf inside the dom0 and I don't know why.
[18:49] <whysyn> i've finally gotten my hands on decent hardware for my ceph test cluster. initially, it was build on a handful of old pc hardware, and iops were abysmal
[18:50] <whysyn> now that i freed up some real servers for it, we'll see how it does
[18:50] <whysyn> if we do go production with it though, the network redundancy is a big concern, hence my question here =P
[18:50] <Tv_> whysyn: that sounds like a perfect use case for either 10gig, or link bonding, or both
[18:51] <tnt> whysyn: Personally I use LACP with each end connected to a different switch of the same stack.
[18:51] <Tv_> whysyn: is there a reason you don't want to go that way?
[18:51] <whysyn> without native support in ceph for multipath, LACP is the route i will be going
[18:52] <Tv_> whysyn: it's *better* closer to the wire; that's where to knowledge of disconnects is
[18:52] <tnt> whysyn: Since it's only used for the root fs and all 'operational' data is stored in rados directly, the RBD perf is not critical which is why I'll live with the performance hit for now.
[18:52] <Tv_> whysyn: you could build the same thing with routing table tricks, but even then it'd be just a single ip address for ceph
[18:53] <whysyn> right now, all of my vsphere storage nodes are using iscsi arrays, i have multiple individual switches in different subnets between the esx hosts and the storage nodes
[18:53] <whysyn> multipath figures it out for me
[18:54] <Tv_> iscsi multipath is something completely different
[18:55] <tnt> whysyn: what switches are you using ?
[18:55] <whysyn> i used LACP when everything over here was on NFS backed storage
[18:55] <whysyn> they're dell 5424's at the moment
[18:55] <tnt> And they support LACP across switch ?
[18:55] <whysyn> but will be upgrading soon
[18:56] <Tv_> iscsi multipart is effectively the same as scsi multipath with is from the days when your data resided on a specific disk chassis and you just needed a working io card & cable to reach it -- that's quite far from the reality of modern day distributed storage
[18:56] * Leseb (~Leseb@5ED01FAC.cm-7-1a.dynamic.ziggo.nl) has joined #ceph
[18:57] <Tv_> and that school of multipath is more about failover than active maximal use of all links
[18:58] <whysyn> no, the dells are not stacked. when i was on nfs i had layered two link agg groups into an active/passive pair
[18:58] <tnt> whysyn: vsphere uses a linux as 'host' ? So I guess you need to use the kernel driver as well ?
[18:58] <Tv_> go with LACP with an L3 xor scheme
[18:59] <whysyn> actually, on the mpio setup with esx, once tuned, i can push 2000MB/s. the switch port graphs for each storage node are almost perfectly balanced
[19:00] <whysyn> in my test setup, i exposed the rbd's via iscsi
[19:00] * loicd (~loic@magenta.dachary.org) has joined #ceph
[19:01] <whysyn> i'm not worried about getting esx to see it. i was worried about making the network for the cluster itself as resilient and fast as possible
[19:08] * houkouonchi-work (~linux@ Quit (Remote host closed the connection)
[19:09] * rosco (~r.nap@ Quit (Quit: *Poof*)
[19:14] * BManojlovic (~steki@ has joined #ceph
[19:16] <amatter> still working on the problem on my production setup. After an hour or so of heavy duty data transfer into the cephfs the kernel driver becomes unresponsive and I get hung task warnings in the kernel log. http://pastebin.com/gVku8RP3 . Does this suggest that kernel driver has lost contact with the ceph cluster? I'm not sure where to investigate.
[19:16] * dilemma (~dilemma@2607:fad0:32:a02:21b:21ff:feb7:82c2) has joined #ceph
[19:16] <Tv_> amatter: the distributed file system still has locking bugs in it; it sounds like you found one
[19:16] <mikeryan> nhm: you in LA now?
[19:17] <dilemma> anyone know, with qemu-rbd, if it's possible to change the monitor IPs on an already attached volume?
[19:17] <Tv_> amatter: http://ceph.com/docs/master/faq/#is-ceph-production-quality
[19:17] <Tv_> mikeryan: he is
[19:17] * JT (~john@astound-64-85-239-164.ca.astound.net) Quit (Ping timeout: 480 seconds)
[19:18] <tnt> dilemma: it shouldn't matter. If the IP of the new mon is in the quorum, it should know about it already.
[19:18] <Tv_> dilemma: i think the ips you pass in are really only used for the initial contact; the client learns of all the active monitors from the first monitor it manages to contact
[19:18] <Tv_> amatter: please file a bug report at http://tracker.newdream.net/
[19:19] <gregaf> amatter: Tv_: that doesn't look like a bug we're familiar with — it's hung up in ceph_msg_kfree?
[19:19] <dilemma> ahh, that's useful info. So the only real concern would be replacing the all of the initial IPs
[19:20] <Tv_> dilemma: essentially, if it's an attached volume, the ips have already been used as much as they ever are
[19:20] <dilemma> and then only if you brought the volume down and back up again without updating your instance config
[19:20] <dilemma> oh, so it never talks to the monitors after initial attach?
[19:20] <Tv_> dilemma: sure it might, but it'll use what it knows of the monitors from the first contact
[19:20] <tnt> it does, but using the learned IP rather than the configured one.
[19:21] <dilemma> understood
[19:21] * houkouonchi-work (~linux@ has joined #ceph
[19:21] * houkouonchi-work (~linux@ Quit (Remote host closed the connection)
[19:22] <dmick> remote meeters: sorry; nothing obviously wrong. We'll try to diagnose in more detail after the meeting
[19:22] <dmick> probably a virus :)
[19:23] <mikeryan> dmick: it's strange, only seems to affect you guys
[19:23] <mikeryan> the other remote participants sound fine
[19:23] <mikeryan> i'm on a phone, and joao on PC sounds fine
[19:23] <dmick> alex was sounding unintelligible to us, but Joao sounds fine and so did you
[19:23] <mikeryan> alex sounded fine to me
[19:24] <dmick> effing technology
[19:24] <mikeryan> you'd think we'd have a handle on this whole VoIP thing by now
[19:25] <joao> AON also sound garbled to me in the beginning; now everything seems to be fairly okay
[19:25] * JT (~john@astound-64-85-239-164.ca.astound.net) has joined #ceph
[19:29] * houkouonchi-work (~linux@ has joined #ceph
[19:36] <joao> gregaf, found the bug I was just talking about in the stand-up
[19:36] <joao> but it's going to be a pain to reproduce it to confirm it has been fixed
[19:37] <dilemma> another question - auth related. It's hard finding good info on cephx. Is there a way to query cephx for a single user (rather than dumping the whole ceph auth list and parsing?)
[19:38] <dilemma> Ideally, I'd like to say "generate a keyring that contains the following list of existing users"
[19:46] <dilemma> ugh, sorting through a dump of some 10k users when I need to retrieve a key is a pain
[19:47] * JT (~john@astound-64-85-239-164.ca.astound.net) Quit (Ping timeout: 480 seconds)
[19:48] * Ryan_Lane (~Adium@c-67-160-217-184.hsd1.ca.comcast.net) has joined #ceph
[19:51] * maelfius (~mdrnstm@ has joined #ceph
[19:54] <gregaf> joao: awesome!
[19:57] <gregaf> dilemma: you can get the key for a specific user with "ceph auth get-or-create-key <entity-name>"
[19:57] <gregaf> though that won't include the caps that user has
[19:57] <Tv_> you pass in the caps
[19:58] <Tv_> that is get-or-create, not get
[19:58] <gregaf> on create, yeah, but you can't do cap retrieval that way
[19:58] <gregaf> if you needed it for some reason
[19:59] * JT (~john@astound-64-85-239-164.ca.astound.net) has joined #ceph
[19:59] <Tv_> right now you'd need to ceph auth list >temp && ceph-authtool temp -p NAME, or something like that
[20:00] <Tv_> oh huh, http://tracker.newdream.net/issues/2407 is marked resolved
[20:00] <Tv_> so we should have "ceph auth get"
[20:00] <Tv_> dilemma: try that ^
[20:00] <gregaf> oh, yep!
[20:01] <gregaf> was looking in the wrong place
[20:02] <dilemma> nice, ceph auth get works
[20:04] <amatter> ok, created bug for hung ceph_msg_kfree http://tracker.newdream.net/issues/3087
[20:27] * chutzpah (~chutz@ has joined #ceph
[20:28] * Ryan_Lane (~Adium@c-67-160-217-184.hsd1.ca.comcast.net) Quit (Quit: Leaving.)
[20:29] * Leseb (~Leseb@5ED01FAC.cm-7-1a.dynamic.ziggo.nl) Quit (Read error: Connection reset by peer)
[20:29] * Leseb (~Leseb@5ED01FAC.cm-7-1a.dynamic.ziggo.nl) has joined #ceph
[20:41] * senner (~Wildcard@68-113-228-222.dhcp.stpt.wi.charter.com) has joined #ceph
[20:45] * iggy (~iggy@theiggy.com) has joined #ceph
[20:50] * whysyn (c7491c4b@ircip2.mibbit.com) Quit (Quit: http://www.mibbit.com ajax IRC Client)
[20:56] <dilemma> with regards to ceph auth, any way I can contribute to the docs here? http://ceph.com/docs/master/control/
[21:15] * jmlowe1 (~Adium@c-71-201-31-207.hsd1.in.comcast.net) has joined #ceph
[21:18] <jmlowe1> I have a question about the stable and dev branches, what are the criteria for creating the next stable branch off of the dev branch?
[21:20] * Ryan_Lane (~Adium@ has joined #ceph
[21:21] * luckky (~73b8421e@2600:3c00::2:2424) has joined #ceph
[21:21] <luckky> hi
[21:22] <luckky> am getting error while running chef-server-webui
[21:22] <luckky> getting fail notice while running webui server
[21:23] <luckky> pls help . how to fix that bug
[21:24] <dilemma> luckky: sounds like you have the wrong channel - chef-server-webui is a separate project form ceph
[21:26] <dilemma> you might try this? http://wiki.opscode.com/display/chef/IRC
[21:30] <sagewk> amatter: i put a patch to try in that bug, for the ceph_d_prune one
[21:30] <joao> gregaf, if you happen to review the code any time soon, please read it assuming that, for state barrier purposes, we have two state maps: one for the leader and other for the provider
[21:30] <joao> somehow I thought that sharing the same map would play nicely whenever we had the leader as the sync provider
[21:33] <luckky> hi dilemma, sry . getting error while configuring radosgw with fastcgiexternelserver
[21:38] * luckky (~73b8421e@2600:3c00::2:2424) Quit (Quit: TheGrebs.com CGI:IRC (Ping timeout))
[21:42] <amatter> sagewk: okay, thanks. I'll give it a try
[21:43] * jmlowe1 (~Adium@c-71-201-31-207.hsd1.in.comcast.net) Quit (Quit: Leaving.)
[21:54] * jmlowe (~Adium@c-71-201-31-207.hsd1.in.comcast.net) has joined #ceph
[21:55] * Cube (~Adium@cpe-76-95-223-199.socal.res.rr.com) Quit (Quit: Leaving.)
[21:58] * Cube (~Adium@cpe-76-95-223-199.socal.res.rr.com) has joined #ceph
[22:28] * Cube (~Adium@cpe-76-95-223-199.socal.res.rr.com) Quit (Quit: Leaving.)
[22:50] * lofejndif (~lsqavnbok@83TAAAH0G.tor-irc.dnsbl.oftc.net) has joined #ceph
[22:54] * Cube (~Adium@ has joined #ceph
[22:55] * nhorman (~nhorman@hmsreliant.think-freely.org) Quit (Quit: Leaving)
[23:03] * jjgalvez (~jjgalvez@cpe-76-175-17-226.socal.res.rr.com) has joined #ceph
[23:05] <sagewk> joao: want to look at wip-mon to see what's coming with the osd thrashing throttling?
[23:17] * dmick (~dmick@2607:f298:a:607:69ac:558c:205e:4144) Quit (Quit: Leaving.)
[23:18] * dmick (~dmick@2607:f298:a:607:d01c:d23e:5613:207e) has joined #ceph
[23:23] * adjohn (~adjohn@ has joined #ceph
[23:27] * lofejndif (~lsqavnbok@83TAAAH0G.tor-irc.dnsbl.oftc.net) Quit (Quit: gone)
[23:31] * pentabular (~sean@adsl-71-141-232-252.dsl.snfc21.pacbell.net) has joined #ceph
[23:31] * aliguori (~anthony@cpe-70-123-140-180.austin.res.rr.com) Quit (Quit: Ex-Chat)
[23:32] * aliguori (~anthony@cpe-70-123-140-180.austin.res.rr.com) has joined #ceph
[23:37] * sagelap1 (~sage@139.sub-166-250-66.myvzw.com) has joined #ceph
[23:41] * sagelap1 is now known as sagelap

These logs were automatically created by CephLogBot on irc.oftc.net using the Java IRC LogBot.