#ceph IRC Log


IRC Log for 2011-03-04

Timestamps are in GMT/BST.

[16:48] -magnet.oftc.net- *** Looking up your hostname...
[16:48] -magnet.oftc.net- *** Checking Ident
[16:48] -magnet.oftc.net- *** Found your hostname
[16:48] -magnet.oftc.net- *** No Ident response
[16:48] * CephLogBot (~PircBot@fubar.widodh.nl) has joined #ceph
[16:48] * neurodrone (~neurodron@cpe-76-180-162-12.buffalo.res.rr.com) has joined #ceph
[16:49] <prometheanfire> CephLogBot: is this channel logged?
[16:50] * allsystemsarego (~allsystem@ has joined #ceph
[17:05] * Nalls (4a8f500a@ircip1.mibbit.com) has joined #ceph
[17:06] <Nalls> Hello
[17:13] <wido> Nalls: hi
[17:13] <wido> prometheanfire: Yes, http://irclogs.ceph.widodh.nl/
[17:16] * Nalls (4a8f500a@ircip1.mibbit.com) Quit (Quit: http://www.mibbit.com ajax IRC Client)
[17:16] <prometheanfire> I was being trite
[17:26] * Meths_ (rift@ has joined #ceph
[17:32] * Meths (rift@ Quit (Ping timeout: 480 seconds)
[17:34] * greglap (~Adium@cpe-76-90-239-202.socal.res.rr.com) Quit (Quit: Leaving.)
[17:38] * eternaleye (~eternaley@ Quit (Ping timeout: 480 seconds)
[17:45] * eternaleye (~eternaley@ has joined #ceph
[17:48] * verwilst (~verwilst@router.begen1.office.netnoc.eu) Quit (Quit: Ex-Chat)
[17:50] * bchrisman (~Adium@c-98-207-207-62.hsd1.ca.comcast.net) Quit (Quit: Leaving.)
[17:53] * greglap (~Adium@ has joined #ceph
[18:05] <sagewk> wido: there?
[18:16] * eternaleye (~eternaley@ Quit (Remote host closed the connection)
[18:16] * eternaleye (~eternaley@ has joined #ceph
[18:19] <_Shiva_> doh - either i'm really too dumb to get radosgw running.. or it's broken ;-)
[18:19] <greglap> _Shiva_: it does work, but that doesn't mean it works in your configuration ;)
[18:19] <greglap> what are you trying to do?
[18:20] * Tv (~Tv|work@ip-66-33-206-8.dreamhost.com) has joined #ceph
[18:20] <_Shiva_> greglap: i've tried lighty and apache - both with different failures .. ;-)
[18:21] <greglap> you're going to have to give me more than that
[18:21] <greglap> although if it's issues with the http server I probably can't do much for you; will have to wait for Yehuda to get in
[18:21] <_Shiva_> (typing a bit more slowly.. )
[18:22] <_Shiva_> i don't know if it's the http server's fault
[18:23] <_Shiva_> what i _got_ working is apache/mod_fastcgi at some extend
[18:23] * Meths_ is now known as Meths
[18:23] * morse (~morse@supercomputing.univpm.it) Quit (Remote host closed the connection)
[18:23] <_Shiva_> i'm able to create a bucket, list the emty bucket
[18:24] <_Shiva_> and while uploading a file to the bucket, (th modified) "s3" segfaults and "s3cmd" tries five times and aborts wuth "checksum failed"
[18:25] <_Shiva_> alas "list" shows the object and "rados ls" shows it, too
[18:26] <greglap> you set this up following the instructions on the wiki?
[18:26] <_Shiva_> and as a sidenote: is it possible by some means to use the "data" pool to create the buckets in..?
[18:27] <greglap> nope — the rados gateway creates a mapping between its emulated S3 buckets and actual rados pools
[18:29] * cmccabe (~cmccabe@ has joined #ceph
[18:30] <_Shiva_> and yes, i've tried the wiki config for both apache and lighty as well as the config mentioned in the radosgw man page
[18:31] <greglap> hmm, okay
[18:33] <greglap> yehudasa: Tv: sagewk: sjust: anybody building anything?
[18:33] <greglap> I may have a workaround for that stupid tcp cork warning but I don't want to restart the distcc daemons under anybody's compile
[18:33] <_Shiva_> i'll try to "get" the file via rados and checksum it.. maybe it's a false alarm to the client..
[18:33] <sjust> greglap: I was
[18:33] <sagewk> go for it
[18:33] <sjust> go for it
[18:34] <Tv> greglap: there are no daemons with the ssh mode!
[18:34] <sagewk> fwiw make-fast is working fine for me after fixing the hardcoded python path in /usr/bin/distcc-pump
[18:34] <yehudasa> _Shiva_: which version of the rados gw are you runnning?
[18:35] <greglap> Tv: so it just sshes into the machine and runs the jobs?
[18:35] <Tv> greglap: yup
[18:35] <greglap> I figured it was just a different communications channel
[18:35] <yehudasa> greglap: not building anything
[18:35] <Tv> greglap: it is; instead of tcp, it uses ssh ;)
[18:35] <greglap> well yes, but I assumed it was talking to a daemon over ssh
[18:35] <Tv> it's basically doing ssh $HOST distcc-daemon --singleshot
[18:35] <greglap> yeah
[18:36] <_Shiva_> yehudasa: all from the squeeze-stable repos (on a squeeze machine)
[18:36] <Tv> which is nice because it also makes your compiles run as *you*
[18:36] <greglap> dammit, that did not fix it
[18:37] <greglap> hmmm, I wonder if setting it in the etc/defaults/distcc file is not enough, or if the guy who responded to my bug is just wrong
[18:37] <Tv> greglap: bug url please?
[18:37] <greglap> http://code.google.com/p/distcc/issues/detail?id=79
[18:37] <yehudasa> _Shiva_: do you have the apache log?
[18:38] * bchrisman (~Adium@70-35-37-146.static.wiline.com) has joined #ceph
[18:38] <_Shiva_> yehudasa: just a sec
[18:40] <greglap> back in 15
[18:40] * greglap (~Adium@ Quit (Quit: Leaving.)
[18:40] <Tv> greglap: hah i think i can workaround that easily in *make-fast*.. do you hate me enough already?-)
[18:43] <Tv> hmm that workaround wasn't enough
[18:43] * yehuda_wk (~quassel@ip-66-33-206-8.dreamhost.com) has joined #ceph
[18:43] * yehudasa (~yehudasa@ip-66-33-206-8.dreamhost.com) Quit (Quit: Leaving)
[18:43] * yehuda_wk is now known as yehudasa
[18:46] <Tv> in your .bashrc, before "[ -z "$PS1" ] && return", put:
[18:46] <Tv> # get distcc to shut up about TCP corking in ssh mode
[18:46] <Tv> # http://code.google.com/p/distcc/issues/detail?id=79
[18:46] <Tv> export DISTCC_TCP_CORK=0
[18:46] <Tv> on flak et al
[18:46] <Tv> kinda fugly
[18:49] <sagewk> tv: rebooting flak
[18:49] * votz (~votz@dhcp0020.grt.resnet.group.UPENN.EDU) Quit (Quit: Leaving)
[18:51] <_Shiva_> yehudasa: pastebin ok?
[18:52] <yehudasa> _Shiva_:yes
[18:53] <sagewk> wido: pushed a few osd recovery patches. can i build/test on noisy/atom? where should i do that?
[18:53] <_Shiva_> yehudasa: http://pastebin.de/15758
[18:55] <yehudasa> _Shiva_: which fastcgi module are you using?
[18:55] <_Shiva_> yehudasa: stock debian squeeze
[18:56] <_Shiva_> or do you mean fcgid vs. fastcgi?
[18:56] <yehudasa> if it's stock debian I guess it's fcgid?
[18:56] * morse (~morse@supercomputing.univpm.it) has joined #ceph
[18:57] <_Shiva_> yehudasa: no - switched to mod_fastcgi
[18:57] <_Shiva_> yehudasa: libapache2-mod-fastcgi-2.4.6-1
[18:57] * Yoric (~David@ Quit (Quit: Yoric)
[18:58] <_Shiva_> yehudasa: but i wanted to use lighty anyway.. ;-) that would be 1.4.28-2
[18:58] <yehudasa> _Shiva_: did you set any special env variables for it?
[18:58] <gregaf> Tv: yeah, I was hoping we could put it somewhere more universal in a distcc config file
[18:59] <_Shiva_> yehudasa: just RGW_DNS_NAME using SetEnv w/i the vhost config
[19:00] <Tv> gregaf: /etc/bash.bashrc perhaps
[19:00] <_Shiva_> (which i actually don't know what it's doing ;-))
[19:00] <gregaf> oh yeah, that's not fugly at all\
[19:00] <sagewk> btw skype at 11 instead of 10:30
[19:01] <yehudasa> _Shiva_: yeah, I can actually see that in the log
[19:01] <yehudasa> _Shiva_: what's your 'ceph -s' output?
[19:02] <_Shiva_> yehudasa: http://pastebin.de/15759
[19:02] <Tv> gregaf: i see the distcc daemon is back on again.. please leave it off when you're done
[19:03] <gregaf> Tv: yeah, error in the config file from lack of versioning control...
[19:03] <gregaf> I thought they needed to be on and it was a mistake that they weren't, my bad
[19:03] <yehudasa> _Shiva_: yeah, looks healthy. Can you get a tcp dump from when you see the problem
[19:03] <yehudasa> ?
[19:04] <yehudasa> e.g., tcpdump -i <interface, e.g., eth0> -s 10000 -w shiva.dump
[19:04] * joshd (~joshd@ip-66-33-206-8.dreamhost.com) has joined #ceph
[19:04] <yehudasa> or just run wireshark and capture
[19:05] <Tv> yehudasa: btw -s0 is easier to type
[19:06] <yehudasa> Tv: you just saved men 30 seconds of my life
[19:06] <yehudasa> ahm.. 'saved me'
[19:06] <Tv> i say this mostly because i spent a day debugging something, because the pcap file was captured with -s1000 instead of -s10000, and i didn't realize it
[19:07] <Tv> less room for error
[19:07] <_Shiva_> yehudasa: with eth0 you mean the interface facing outside or the ceph?
[19:07] <yehudasa> yeah, I actually used to use 20000 usually so that even if you miss one digit you end up better
[19:08] <yehudasa> _Shiva_: the interface facing the http
[19:08] <yehudasa> oh, and also if you have any ceph logs on the gateway it might be of help
[19:09] <yehudasa> but otoh, even if you have them you probably don't have the right logging turned on\
[19:10] <yehudasa> so if you're able to get those logs (should be in /var/log/ceph) then set 'debug ms = 1' in your global section at /etc/ceph/ceph.conf
[19:10] <yehudasa> I'm trying to isolate the problem
[19:11] <yehudasa> it has a symptom of another problem I used to see but you're not using the right fastcgi module for it to actually occur
[19:13] <_Shiva_> yehudasa: may i restrict the pcap to port 80 ? ;-)
[19:14] <yehudasa> _Shiva_: yes
[19:37] <cmccabe> libcommon.a(MonClient.o): In function `MonClient::get_monmap_privately()':
[19:37] <cmccabe> /home/cmccabe/src/ceph/src/mon/MonClient.cc:176: undefined reference to `SimpleMessenger::register_entity(entity_name_t)'
[19:37] <cmccabe> /home/cmccabe/src/ceph/src/mon/MonClient.cc:178: undefined reference to `SimpleMessenger::start(bool)'
[19:37] <cmccabe> /home/cmccabe/src/ceph/src/mon/MonClient.cc:204: undefined reference to `SimpleMessenger::wait()'
[19:37] <cmccabe> libcommon.a(MonClient.o): In function `Accepter':
[19:37] <cmccabe> /home/cmccabe/src/ceph/src/./msg/SimpleMessenger.h:103: undefined reference to `vtable for SimpleMessenger::Accepter'
[19:39] <gregaf> looks like a linking issue with the Makefile
[19:39] <cmccabe> why is simplemessenger not in libcommon?
[19:41] <cmccabe> on the other hand, mon/MonClient.cc is in libcommon, and it uses SimpleMessenger extensively
[19:41] <gregaf> probably a historical artifact of something, not sure though
[19:42] <cmccabe> not sure why the compiler picked this particular moment to whine about the missing symbols
[19:42] <cmccabe> but I got this while compiling dupstor, which includes libcommon but not SimpleMessenger
[19:42] <gregaf> well that would be why, then
[19:42] <gregaf> everything else that needs the SimpleMessenger includes it
[19:42] <gregaf> wtf is dupstore?
[19:43] <cmccabe> looks like mon/MonClient.cc has been around for a while
[19:43] <cmccabe> so this isn't a new issue
[19:44] <cmccabe> gregaf: I don't know. It includes eobfs/Ebofs.h, so it's got a history
[19:44] <cmccabe> gregaf: actually the include is commented out, but you get the idea.
[19:45] <gregaf> are you using make-fast or something?
[19:45] <cmccabe> no
[19:45] <gregaf> hmm, dunno then
[19:45] <cmccabe> using profiler though
[19:45] <gregaf> I don't think we build with-debug too often but I dunno what's changed about it
[19:46] <gregaf> oh, hmm
[19:47] <gregaf> does your cpu profiling stuff use the messenger at all?
[19:47] <cmccabe> no
[19:47] <gregaf> via logging, maybe?
[19:47] <cmccabe> maybe if it pulls it in via LogClient
[19:49] <Tv> news to me: Amazon EBS is apprently done with GNBD: http://sourceware.org/cluster/gnbd/
[19:50] <cmccabe> tv: this is the first I've even heard of GNBD. I wonder how it's different from DRBD?
[19:52] <Tv> cmccabe: DRBD pairs of machines, IIRC
[19:52] <Tv> *is
[19:52] <bchrisman> can't tell if that's derived from the old NBD….
[19:53] <bchrisman> guess if they know what they're doing, they don't need a generic protocol like iSCSI..
[19:53] <cmccabe> tv: yeah, I saw a bunch of discussions of drbd for master-master hot spare applications
[19:53] <Tv> source: http://openfoo.org/blog/archive.html
[19:53] <cmccabe> tv: I guess the next logical question is how GNBD differs from RADOS :)
[19:54] <cmccabe> tv: or rather rbd
[19:54] <gregaf> cmccabe: yeah, the LogClient talks to the monitor :)
[19:54] <gregaf> and dupstore doesn't use the SimpleMessenger in its own code
[19:55] <cmccabe> gregaf: it looks like putting SimpleMessenger in common resolves this...
[19:55] <gregaf> yeah
[19:55] <gregaf> I'm not sure if that's appropriate or not
[19:55] <gregaf> our Makefile makes me nervous
[19:55] <sagewk> cmccabe: re:SimpleMessenger, ages and ages ago it had to be compiled directly during the last compile step for some reason i have long since forgotten.
[19:55] <gregaf> we should probably audit and reorganize it soonish, based on all the updates and what I'm hearing from people
[19:55] <cmccabe> gregaf: well, if it isn't, then stuff that uses SimpleMessenger should probably not be in libcommon... IMO
[19:56] <Tv> gnbd looks like a fairly traditional client/server setup, not inherently distributed the way ceph is
[19:56] <Tv> e.g. the web makes no mention of smarts about rebalancing the storage etc; it seems gnbd can only do that if you have a SAN
[19:56] <cmccabe> personally, I would like to see some things split out into libraries which are currently either in libcommon or randomly injected into apps with .cc files
[19:57] <Tv> gregaf: CMake?-)
[19:57] <cmccabe> haha... yes, that too. :)
[19:57] <Tv> cmccabe: yes
[19:57] <Tv> cmccabe: i will need to redo libcommon to get crypto stuff working right
[19:57] <cmccabe> I think converting it over to CMake would be less effort than you think
[19:57] <cmccabe> given the large amount of work needed to do stuff in automake
[19:57] <Tv> let's talk about that on the call
[19:57] <cmccabe> I would estimate it at about 3 * usual_autopain_incident
[20:00] <Tv> hahaha "CMake seems to have inherited the worst of almost every build system that was developed in the last few years."
[20:00] <Tv> the web is not unanimous
[20:00] <bchrisman> cmccabe: 'pain in units of automake' :)
[20:00] <cmccabe> tv: there's always some guy who hates everything, probably thinks haskell is the solution
[20:01] <Tv> it's a cabal (pun intended)
[20:01] <cmccabe> tv: I've been through one raw makefile -> CMake conversion, and led another
[20:02] <cmccabe> tv: and I can say it's a big improvement
[20:02] <cmccabe> tv: the truth is that once your project gets big enough, raw makefiles get unmanageable because of the lack of dependency management (need to manually specify which .cc depends on which .h, etc.)
[20:03] <wido> sagewk: I'm here
[20:03] <Tv> oh make is horrible
[20:03] <wido> Yes, you can build on atom / noisy
[20:03] <wido> the sources are on /usr/src/ceph on noisy, that's where I pull the stuff
[20:03] <Tv> but i'm not convinced generating makefiles is the right solution
[20:03] <wido> the key of noisy is loaded on atom, so you can scp the code to atom and deploy it there
[20:03] <Tv> some day something like https://github.com/apenwarr/redo might be realistic
[20:03] <cmccabe> tv: CMake works very well and there's just one generation step
[20:04] <Tv> but it's definitely not there yet
[20:04] <cmccabe> tv: it's CMakeFiles -> Makefiles. And it will transparently redo them when files move or something changes.
[20:04] <cmccabe> tv: there's no foo generating bar, generating baz, generating foo2, like with automake
[20:04] <wido> btw, I got my 8 remaining Atom boards today :) Just waiting the power supplies, should have a 72TB / 36 OSD cluster running within two weeks :)
[20:04] <cmccabe> tv: I have also used cons, a build system written entirely in Perl.
[20:05] <cmccabe> tv: It had some advantages... basically it has its own distcc built-in, and you can write "conscripts" in raw perl
[20:05] <cmccabe> tv: but overall, CMake is simpler and thus better
[20:05] <cmccabe> tv: there was also a remake of cons in python called SCons.
[20:05] <Tv> i've used that
[20:06] <Tv> it was not all that fun
[20:06] <cmccabe> tv: The truth is, though, CMake has been used for big projects like KDE
[20:06] <Tv> mmm llvm uses cmake, that's a pretty big endorsement
[20:06] <cmccabe> tv: it's usable for big projects and it works well.
[20:06] <Tv> (kde isn't, for me)
[20:06] <cmccabe> tv: haha
[20:06] <sagewk> wido: i pushed a couple patches
[20:06] <sagewk> wido: can you test, and/or give me a rundown (email?) on how/where i shoudl be building and testing on those boxes?
[20:06] <cmccabe> tv: CMakeFiles are written in a domain-specific language that is a good compromise between flexibility and simplicity
[20:08] <sagewk> ok let's skype!
[20:16] * Yoric (~David@dau94-10-88-189-211-192.fbx.proxad.net) has joined #ceph
[20:32] <wido> sagewk: you've got mail
[20:33] <sagewk> wido: thanks
[20:34] * fzylogic (~fzylogic@ Quit (Quit: fzylogic)
[21:01] <Tv> gregaf: i see your qemu problem
[21:01] <Tv> it's the initrd i believe
[21:01] <Tv> but the darn thing explicitly said it didn't install a bootloader
[21:01] <Tv> arms are almost all pure embedded and have custom bootloaders :(
[21:02] <Tv> and booting without initrd seems to fail
[21:03] <Tv> need to find another, non-install, initrd for it
[21:08] <Tv> of course, there's one just right inside the disk image.. :(
[21:11] <Tv> whee ubuntu livecd with the arm disk image accessible to it.. let's see what we can do
[21:19] <Tv> gregaf: copy flak:~tv/initrd.img-2.6.32-5-versatile and run
[21:19] <Tv> qemu-system-arm -M versatilepb -hda hda.img -cdrom debian-6.0.0-armel-CD-1.iso -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile -append "root=/dev/sda1" -m 256 -monitor stdio
[21:20] <Tv> 650 bogomips vs 12000 bogomips of my desktop machine
[21:20] <Tv> have fun compiling ceph
[21:28] <Tv> and give it more memory ;)
[21:36] <gregaf> Tv: okay, thanks!
[21:42] <_Shiva_> yehudasa: still there?
[21:44] * lxo (~aoliva@ Quit (Read error: Operation timed out)
[21:45] <_Shiva_> yehudasa: actually, i seem to have the same error as: http://discussion.dreamhost.com/thread-128157-post-134230.html
[21:46] <_Shiva_> yehudasa: the file gets uploaded correctly and has the correct md5 (checked with getting the object through rados directly and regetting through s3cmd)
[21:47] <yehudasa> _Shiva_: yes
[21:47] <_Shiva_> yehudasa: tcpdump shows everything ok - except the last packet has an "incorrect checksum"
[21:47] <_Shiva_> like:
[21:47] <_Shiva_> > Flags [P.], cksum 0xa3d2 (incorrect -> 0x5dd0), seq 1:136, ack 276, win 215, options [nop,nop,TS val 10062570 ecr 13777618], length 135
[21:49] <yehudasa> _Shiva_: that doesn't necessarily mean anything, although it might be a problem
[21:49] <_Shiva_> (and i've switched using lighttpd again - exactly the same behaviour as with apache)
[21:50] <yehudasa> sometimes you'd see that checksum in the tcpdump because the checksum calculation is being handed out to the interface
[21:50] <yehudasa> where did you capture on the radosgw machine or on the client?
[21:51] <_Shiva_> on the gw
[21:51] <yehudasa> try on the client?
[21:51] <_Shiva_> just a sec
[21:54] <_Shiva_> i'll take "-vv -X -i eth1 -s 1000" as a cmdline
[21:54] <yehudasa> can you '-s 0' instead?
[21:54] <yehudasa> the 1000 is too short
[21:55] <_Shiva_> 'k
[21:55] <_Shiva_> and i reduced the filesize put ;-)
[21:55] <_Shiva_> just 10 bytes now :)
[21:57] <_Shiva_> yehudasa: http://looking.at/shiva.dump
[21:57] <_Shiva_> that's on the client
[21:58] <yehudasa> alright
[22:02] * WesleyS (~WesleyS@ has joined #ceph
[22:04] * lxo (~aoliva@ has joined #ceph
[22:04] <yehudasa> _Shiva_: everything looks good there..
[22:07] <_Shiva_> i'll try again with wido's libs3 git master...
[22:08] <yehudasa> _Shiva_: which one are you using now?
[22:08] <_Shiva_> s3cmd
[22:08] <_Shiva_> 1.0.0
[22:09] <_Shiva_> (github ist stalled...)
[22:10] <yehudasa> well, it's a different tool I guess?
[22:10] <_Shiva_> yep http://s3tools.org/s3cmd
[22:12] <yehudasa> _Shiva_: how did you make it go to your server instead of amazon's
[22:12] <yehudasa> ?
[22:13] <_Shiva_> yehudasa: just by editing ~/.s3cfg
[22:13] <wido> _Shiva_: I've tried s3cmd too, that one kept failing
[22:13] <wido> never really found out why
[22:13] * WesleyS (~WesleyS@ Quit (Quit: WesleyS)
[22:15] <yehudasa> yeah, fails for me now too
[22:15] <yehudasa> so it's a tool compatibility
[22:16] <yehudasa> I'll try debugging it
[22:19] <wido> yehudasa: I had issues with creating a bucket for example
[22:22] <_Shiva_> wido: i've just created one flawlessly
[22:22] <_Shiva_> libs3 ist working fine btw..
[22:22] <_Shiva_> . o 0 ( argh )
[22:23] <yehudasa> oh, I bet it's because we don't replay with ETag
[22:23] <yehudasa> reply
[22:25] <yehudasa> II'll fix that
[22:27] <wido> sagewk: I'm going afk, like always, feel free to (ab)use those boxes
[22:27] <sagewk> ok thanks!
[22:28] <wido> thanks for looking at this! ttyl
[22:30] <Tv> state of automake: i need to add the crypto cflags to *4* different places, to get it to build right
[22:31] <Tv> still, easier than reworking everything right now
[22:37] <Tv> waah the command line tools reading ceph.conf from cwd are starting to piss me off
[22:38] <Tv> orr, maybe that is a different code change that now has made everything try to log to /var/log again
[22:38] <Tv> either way, waah
[22:40] <gregaf> Tv: pretty sure they'll only try to read from cwd if you don't specify a conf file on the command line
[22:40] <darkfaded> Tv: time for a short break
[22:41] <darkfaded> gregaf: they could sorta look at /etc/ceph before that, for Tv's sanity :)
[22:41] <gregaf> that's quite the wrong order
[22:42] <Tv> gregaf: there has been no reason to provide a config file to osdmaptool and friend, before
[22:42] <Tv> reading config from cwd without being asked to is just wrong
[22:42] <darkfaded> gregaf: okay, admitedly.
[22:42] <Tv> show me an established unix tool that does that
[22:42] <gregaf> now that's not fair to ask me and you know it :p
[22:42] <darkfaded> hehe
[22:42] <Tv> but even more so, why do simple file manipulation tools need config files
[22:43] <gregaf> you mean the tools that need to know how many of each daemon type to set up?
[22:43] <gregaf> and what hosts they live on?
[22:43] <gregaf> maybe there's a better way to set it up, but most of those tools need some or all of the data that's in a config file
[22:44] <darkfaded> gregaf: i just thought about it another time, lowlevel debugstuff might expect a cfg file in the working directory
[22:45] <darkfaded> but everything else i'd expect to only look at the standard config dir
[22:45] <Tv> gregaf: "osdmaptool --createsimple 3 myosdmap"
[22:49] <Tv> rebasing to latest master made that gripe go away again
[22:49] <Tv> (the /var/log error messages spewed on stderr made clitests fail)
[22:49] <gregaf> ah, yeah, there was some churn in the logging code
[22:49] <Tv> now, back to debugging nss.. error code -8189, yay
[23:06] <yehudasa> _Shive_: yeah, that was the issue, I pushed a fix to the master branch and also pushing one for the next branch so it'd be fixed at 0.25
[23:06] <yehudasa> ahmm.. _Shiva_
[23:06] <_Shiva_> wow thanks
[23:09] <_Shiva_> might affect some other s3-tools, too - like "cyberduck".. haven't tried it though
[23:10] <cmccabe> darkfaded: the utiltiies that read ceph.conf use the standard search path now, which is /etc/ceph/ceph.conf, ~/.ceph/config, ceph.conf
[23:11] <yehudasa> oh, I actually pushed it to the 'rgw' branch, but that doesn't matter, it'll be in next soon
[23:11] <cmccabe> darkfaded: you can override that standard search path with -c
[23:12] <cmccabe> tv, darkfaded: the general assumption is that ceph clusters are pretty big beasts with a lot of configuration. You don't usually have multiple ones on the same machine. So in the common case for utilities and daemons, we just grab /etc/ceph/ceph.conf rather than requiring the path as an argument to everything.
[23:13] <Tv> cmccabe: that's completely unrelated to 1) small tools reading config they don't really need/use 2) reading config from cwd by default
[23:13] <Tv> 1) is just keeping it pretty, 2) might even have security consequences
[23:14] <cmccabe> tv: if it were up to me, we wouldn't read ceph.conf from cwd
[23:14] <darkfaded> i agree on 2) mostly because superuser stuff and CWD really isn't good, but besides i just wanted to cheer up Tv
[23:15] <cmccabe> tv: but that is the way we've done it for a while. It's just a one-line change to config.cc to eliminate that, but everyone has to agree.
[23:15] <Tv> shouldn't be hard to make development-time vstart.sh etc use -C ceph.conf, and then get rid of the cwd in list of config files to read
[23:15] <darkfaded> i have to use gluster on two projects right now so i'm loving ceph no matter where it reads it's config.
[23:15] <cmccabe> vstart.sh does use -c now I think?
[23:16] <cmccabe> yep, vstart.sh tacks ARGS on to every ceph command, which is "-c ceph.conf"
[23:16] <Tv> oh it gets better.. the textual error message for this is ""
[23:16] <Tv> gah
[23:16] <darkfaded> cheering up fail.
[23:19] * lxo (~aoliva@ Quit (Remote host closed the connection)
[23:41] * allsystemsarego (~allsystem@ Quit (Quit: Leaving)
[23:57] * lxo (~aoliva@ has joined #ceph

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