--- Log opened Fri May 30 00:00:24 2014 00:10 -!- celebdor: has quit [Quit: WeeChat 0.4.3] 00:12 -!- rmatinata (Ricardo Marin Matinata): has joined #vdsm 01:30 -!- nsoffer: has quit [Read error: Connection reset by peer] 01:39 -!- nsoffer (Nir Soffer): has joined #vdsm 01:47 -!- apuimedo|lunch (antoni): has joined #vdsm 01:49 -!- AlbertoSilva (AlbertoSilva): has joined #vdsm 01:56 -!- gpadgett: has quit [Quit: Leaving] 02:25 -!- apuimedo|lunch: has quit [Ping timeout: 240 seconds] 02:35 -!- moolit: has quit [Quit: Leaving.] 02:36 -!- adahms: has quit [Ping timeout: 252 seconds] 02:54 -!- AlbertoSilva (AlbertoSilva): has joined #vdsm 02:55 -!- adahms (Andrew Dahms): has joined #vdsm 03:05 -!- nsoffer: has quit [Read error: Connection reset by peer] 03:15 -!- nsoffer (Nir Soffer): has joined #vdsm 03:22 -!- shaohef: has quit [Quit: Leaving.] 03:45 -!- bala (purple): has joined #vdsm 04:10 -!- mliu (purple): has joined #vdsm 04:10 -!- mliu: has left #vdsm [] 04:24 -!- shaohef (shaohef): has joined #vdsm 04:33 -!- nsoffer: has quit [Ping timeout: 240 seconds] 04:50 -!- bala: has quit [Ping timeout: 252 seconds] 05:27 -!- aravindavk (Aravinda): has joined #vdsm 05:39 -!- wgao: has quit [Ping timeout: 255 seconds] 05:50 -!- shaohef: has quit [Quit: Leaving.] 05:50 -!- shaohef (shaohef): has joined #vdsm 06:00 -!- shaohef: has quit [Ping timeout: 252 seconds] 06:01 -!- shaohef (shaohef): has joined #vdsm 06:19 -!- shaohef: has quit [Ping timeout: 264 seconds] 07:13 -!- adahms: has quit [Ping timeout: 260 seconds] 07:19 -!- shaohef (shaohef): has joined #vdsm 07:22 -!- shaohef1 (shaohef): has joined #vdsm 07:25 -!- shaohef: has quit [Ping timeout: 265 seconds] 07:26 -!- adahms (Andrew Dahms): has joined #vdsm 07:35 -!- bala (purple): has joined #vdsm 08:24 -!- sbonazzo (purple): has joined #vdsm 08:37 -!- mskrivanek_away is now known as mskrivanek 08:45 -!- fromani (Francesco Romani): has joined #vdsm 08:58 -!- adahms: has quit [Quit: Leaving] 09:03 -!- shaohef (shaohef): has joined #vdsm 09:04 -!- shaohef1: has quit [Ping timeout: 252 seconds] 09:05 -!- mliu1 (purple): has joined #vdsm 09:05 -!- mliu1: has left #vdsm [] 09:22 -!- timothy (Timothy Asir): has joined #vdsm 09:26 -!- xfrancis (Xavi Francisco): has joined #vdsm 09:33 -!- fsimonce (Federico): has joined #vdsm 10:03 -!- xaviern (Xavier): has joined #vdsm 10:25 -!- osvoboda (osvoboda): has joined #vdsm 10:32 -!- shaohef: has quit [Quit: Leaving.] 10:38 -!- mliu (purple): has joined #vdsm 10:38 -!- mliu: has left #vdsm [] 10:38 -!- shaohef (shaohef): has joined #vdsm 10:54 -!- fromani: has quit [Ping timeout: 240 seconds] 10:54 -!- fromani (Francesco Romani): has joined #vdsm 11:02 -!- fromani_ (Francesco Romani): has joined #vdsm 11:02 -!- fromani_: has quit [Client Quit] 11:02 -!- fromani_ (Francesco Romani): has joined #vdsm 11:03 -!- fromani: has quit [Ping timeout: 265 seconds] 11:03 -!- fromani_ is now known as fromani 11:04 < fromani> bad connection today 11:14 -!- #vdsm,#theforeman xaviern: has quit [Ping timeout: 252 seconds] 11:18 -!- fromani_ (Francesco Romani): has joined #vdsm 11:19 -!- fromani_: has quit [Client Quit] 11:20 -!- fromani_ (Francesco Romani): has joined #vdsm 11:20 -!- fromani: has quit [Ping timeout: 252 seconds] 11:29 -!- fromani (Francesco Romani): has joined #vdsm 11:29 -!- fromani_: has quit [Ping timeout: 240 seconds] 11:36 -!- fromani: has quit [Ping timeout: 276 seconds] 11:49 -!- fromani (Francesco Romani): has joined #vdsm 11:53 -!- nsoffer (Nir Soffer): has joined #vdsm 12:11 -!- shaohef: has quit [Quit: Leaving.] 12:15 -!- osvoboda is now known as osvoboda_away 12:17 -!- bala: has quit [Ping timeout: 245 seconds] 12:18 -!- aravindavk: has quit [Ping timeout: 255 seconds] 12:33 -!- fromani_ (Francesco Romani): has joined #vdsm 12:33 -!- #vdsm fsimonce: has quit [Quit: Coyote finally caught me] 12:35 -!- fromani: has quit [Ping timeout: 240 seconds] 12:35 -!- mojaves (Francesco Romani): has joined #vdsm 12:36 -!- aravindavk (Aravinda): has joined #vdsm 12:38 -!- fromani_: has quit [Ping timeout: 264 seconds] 12:38 -!- fromani_ (Francesco Romani): has joined #vdsm 12:41 -!- mojaves: has quit [Ping timeout: 264 seconds] 12:41 -!- mojaves (Francesco Romani): has joined #vdsm 12:41 -!- fromani_: has quit [Read error: Connection reset by peer] 12:42 -!- fsimonce (Federico): has joined #vdsm 12:45 -!- xaviern (Xavier): has joined #vdsm 12:49 -!- osvoboda_away is now known as osvoboda 12:51 -!- mojaves: has quit [Ping timeout: 252 seconds] 12:52 -!- fromani (Francesco Romani): has joined #vdsm 12:56 -!- #vdsm,#theforeman xaviern: has quit [Ping timeout: 265 seconds] 12:58 -!- fromani: has quit [Quit: Leaving] 12:59 -!- fromani (Francesco Romani): has joined #vdsm 12:59 -!- apahim: has quit [Ping timeout: 252 seconds] 13:00 -!- osvoboda is now known as osvoboda_away 13:00 -!- aravindavk: has quit [Ping timeout: 240 seconds] 13:00 -!- osvoboda_away is now known as osvoboda 13:02 -!- fromani: has quit [Client Quit] 13:02 -!- fromani (Francesco Romani): has joined #vdsm 13:12 -!- apahim (Amador Pahim): has joined #vdsm 13:13 -!- aravindavk (Aravinda): has joined #vdsm 13:34 -!- osvoboda is now known as osvoboda_away 13:49 < fromani> fsimonce: ping 13:50 < fsimonce> fromani, pong 13:51 < fromani> fsimonce: hi, I was attempting to track down the rationale behind the NFS mount parameters 13:51 < fromani> but history in git hasn't been very helpful so far 13:51 < fromani> in particular the timeout/retrans settings 13:53 -!- bala1 (purple): has joined #vdsm 13:53 < fsimonce> ok, any specific doubt? 13:55 < fromani> fsimonce: in the current code we do have timeout=600 (deciseconds) retrans=6 and the total time is 6 minutes which is somehow strange 13:55 < fromani> I was trying to understand if there is a specific reason for this value 13:57 < fromani> but it seems these value hare like this since the beginning of time... 13:57 < fsimonce> fromani, since we're using soft mounts we wanted to have more retries before giving up 13:57 < fromani> are* 13:57 < fsimonce> fromani, 6 is the double of the default 13:58 < fromani> fsimonce: understood 13:59 < fsimonce> fromani, with an hard mount I don't think qemu will receive an io error... and wouldn't pause (it would just get stuck)... as far as I understand 13:59 < fromani> fsimonce: would it make sense to lower the `timeo' and increase the `retrans' setting? I was just trying to see if we can shave some time here 14:00 < fsimonce> fromani, uhm, I don't think it will change anything, you probably need to experiment a little bit, maybe things changed in qemu lately 14:01 < fromani> fsimonce: got it. I'll play with recent QEMU to see if something changed 14:01 < fsimonce> fromani, great thanks, send me the results, I'm interested 14:01 < fromani> fsimonce: sure! 14:08 -!- rmatinata: has quit [Ping timeout: 276 seconds] 14:15 -!- aravindavk: has quit [Ping timeout: 265 seconds] 14:22 -!- osvoboda_away is now known as osvoboda 14:28 -!- edu__ (Eduardo): has joined #vdsm 14:29 -!- edu__: has quit [Client Quit] 14:29 -!- nsoffer: has quit [Read error: Connection reset by peer] 14:30 -!- nsoffer (Nir Soffer): has joined #vdsm 14:37 -!- danken (purple): has joined #vdsm 14:37 -!- mode/#vdsm: by ChanServ 14:41 -!- nsoffer: has quit [Read error: Connection reset by peer] 14:47 -!- AlbertoSilva (AlbertoSilva): has joined #vdsm 14:55 -!- bala1: has quit [Ping timeout: 264 seconds] 14:56 -!- rmatinata (Ricardo Marin Matinata): has joined #vdsm 15:02 -!- celebdor (celebdor): has joined #vdsm 15:02 < celebdor> danken: I'm not online until now because I needed peace of mind for QoS 15:03 < celebdor> danken: I got it without using iptables 15:03 < celebdor> I'm doing a write up of the solution 15:03 < celebdor> very detailed 15:03 < celebdor> with the iperf experiments 15:03 < celebdor> I'll probably make it a blog post 15:03 < celebdor> and then distill it into simple words for the oVirt wiki 15:06 < sbonazzo> fsimonce: ping 15:06 < fsimonce> sbonazzo, pong 15:07 < sbonazzo> fsimonce: is there a way to query VDSM about the block size used on the destination sdUUID, spUUID, volUUID? Looks like createVolume accept size in blocks 15:07 < sbonazzo> fsimonce: when called from vdsm.vdsmcli 15:08 < sbonazzo> fsimonce: I need to create a volume of 1Mb 15:09 < fsimonce> sbonazzo, you're referring to block domains I assume 15:09 < sbonazzo> fsimonce: both block and nfs domains, we're unifying the way we're allocating the files lockspace/metadata 15:10 < sbonazzo> fsimonce: http://gerrit.ovirt.org/28237 15:11 < fsimonce> sbonazzo, ok because on block you have the lvm granularity so you can't have a 1M volume, min size is 128M 15:12 < fsimonce> sbonazzo, anyway if you want to use bytes as unit you have to send a string :-) (not an int) 15:12 < sbonazzo> fsimonce: good to know, I'll send string then 15:16 -!- mskrivanek is now known as mskrivanek_away 15:16 < sbonazzo> fsimonce: thanks for your help 15:17 < fsimonce> sbonazzo, np, is it working? 15:17 < sbonazzo> fsimonce: we're still working on it 15:19 -!- bala1 (purple): has joined #vdsm 15:21 <@danken> celebdor: wonderful 15:23 < celebdor> danken: now testing policing rate in filters vs embedded htb for accuracy 15:24 -!- bala2 (purple): has joined #vdsm 15:24 < osvoboda> danken: Resent you a response to your mail. Last time, I used the wrong Subject line. 15:24 -!- fromani: has quit [Ping timeout: 276 seconds] 15:25 -!- bala1: has quit [Ping timeout: 252 seconds] 15:30 -!- gpadgett (Greg Padgett): has joined #vdsm 15:37 -!- fromani (Francesco Romani): has joined #vdsm 15:41 < fromani> danken: I wish I could make some sense of this segfault issue 15:42 < celebdor> fromani: did you report it to the nose people? 15:42 < celebdor> I'd let them deal with it 15:42 < celebdor> and in the meantime we just run the tests split 15:42 < fromani> celebdor: not yet, but I guess is our best shot right now. 15:45 < fromani> celebdor: will file a nose bug report shortly 15:46 < celebdor> fromani: thanks! 15:46 -!- bazulay (purple): has joined #vdsm 16:10 <@danken> osvoboda: I saw your email, but did not get to read it.... I expected a boolean answer... 16:10 <@danken> I only one or two tests fail after rebase - just fix the tests. 16:17 -!- osvoboda is now known as osvoboda_away 16:17 < fromani> celebdor: out of curiosity, can you reproduce the segfault on any box of yours? 16:18 < celebdor> fromani: haven't tried :P 16:18 * fromani wonders if he's cursed 16:18 * celebdor is immersed in the underworld of tc 16:19 < fromani> tc the linux QoS utility? 16:19 < celebdor> yup 16:19 < celebdor> I'm adding vdsm network traffic shaping for networks (we currently have for vnics, that libvirt provides) 16:20 < celebdor> and I'm playing for weeks (each friday) with configurations that scale and are somewhat accurate 16:20 < celebdor> and fair between networks 16:20 < celebdor> and generic 16:20 < celebdor> fromani: as you can see, a world of enjoyment :-) 16:21 < fromani> celebdor: I see :) 16:22 < celebdor> currently trying to understand why tbf rate limiting to 4mbps gives me 38mbps 16:22 < celebdor> xD 16:24 < celebdor> probably too big burst setting 16:28 < celebdor> fuuuuuuuuuuuuuuu! My machine with all the setting rebooted 16:28 < celebdor> spontaneously 16:28 < celebdor> fuuuuuuuuuuu 16:29 < fromani> celebdor: on the bright side, you may have found a bug in the linux networking code... 16:29 < celebdor> setting too small burst on a tbf qdisc 16:29 < celebdor> if we crash because of that 16:29 < celebdor> it is beyond ridiculous 16:37 < celebdor> ok, I reconfigured it 16:37 < celebdor> let's see if the crash is consistent 16:39 < celebdor> nope 16:39 < celebdor> it doesn't crash now 16:39 < celebdor> weird... 16:40 < celebdor> anyway, tbf works with the accuracy of a bazooka in an archery range 16:40 < celebdor> for speeds over 1mbps 16:43 <@danken> celebdor: ;-) 16:44 -!- shaohef (shaohef): has joined #vdsm 16:44 * celebdor just wanted to avoid an htb hierarchy 16:45 < celebdor> just for limiting to have to have a qdisc and a class instead of a tbf qdisc 16:45 < celebdor> sucks a bit 16:49 -!- osvoboda_away is now known as osvoboda 16:52 < osvoboda> danken: Yes, removing the bond solves our issues. 16:53 < osvoboda> danken: There is one test which does not remove the bond, which directly results in its failure. 16:54 <@danken> osvoboda: can you suggest a fix for this test? 16:54 < celebdor> osvoboda: which test? 16:55 < osvoboda> testSetupNetworksResizeBond 16:55 < celebdor> osvoboda: well, obviously this one is not supposed to remove the bond... 16:56 < celebdor> osvoboda: and why should it? 16:56 < celebdor> what is it breaking for you? 16:56 < osvoboda> celebdor: Of course I don’t want to remove the bond in this test :-) 16:56 < celebdor> or you mean remove it at the end of the test? 16:56 < osvoboda> celebdor: Yes, this must happen. 16:57 < celebdor> osvoboda: and it does, right? 16:59 < osvoboda> celebdor: The checks for bonding options work, so apparently, the bond is removed. Moreover, there are setupNetwork (& friends) calls which delete network using the bonds. 17:00 * celebdor doesn't understand what exactly is the issue 17:02 < osvoboda> celebdor: In assertBondExists, I check that the options specified and obtained are exactly the same, which is not the case in this test. The option miimon=150 "leaks" from the first call to setupNetworks and is unexpected in the second call, which only modifies the bonding mode. 17:03 < celebdor> one sec 17:03 < osvoboda> danken, celebdor: I can "fix the tests". I can make the check in assertBondExists behave exactly as Bond.areOptionsApplied. This is far less strict (does not check that sets of options are the same) but maybe this is enough for now. 17:06 < celebdor> osvoboda: from reading the test 17:06 < celebdor> the bond mode is changed 17:06 < celebdor> and it doesn't have any network users 17:06 < osvoboda> celebdor: Oh, I forgot to tell you. 17:07 < celebdor> probably handlebonding could add a similar code to what I did 17:07 < celebdor> sorry 17:07 < osvoboda> celebdor: It should have been removed, right? 17:07 < celebdor> editbonding 17:07 < celebdor> could remove it and recall configure on it 17:07 < celebdor> that would solve the issue 17:09 < osvoboda> celebdor: Yep. I heard you made a CLI tool using just setupNetworks, would this mean addNetwork & co. would be removed? 17:10 < celebdor> osvoboda: the api calls are to be removed in oVirt 4.0 17:10 < celebdor> the command line tool that I'm making has 17:10 < celebdor> "network add" and "network del" 17:10 < celebdor> so that's fine 17:10 < osvoboda> Very clear :-) 17:10 < osvoboda> *clean 17:12 < osvoboda> celebdor: What do you think about my check in assertBondExists, though? Should I make it less strict to mirror areOptionsApplied? 17:12 < celebdor> nope, not for now 17:12 < celebdor> I think the fix to editBondings is fix enough, isn't it 17:12 < celebdor> ? 17:13 < osvoboda> celebdor: It would fix the tests, yes. 17:15 < osvoboda> celebdor, danken: I am still having an issue with not resetting options of a bond. 17:16 < osvoboda> There are a few options that can be changed regardless of the bond state, it can be used and the options just changed on the fly. 17:17 < celebdor> like_ 17:17 < celebdor> ? 17:17 < osvoboda> celebdor: Typing :-) 17:17 < osvoboda> This is just a theory, not a use-case, but: Imagine the user sets options to "miimon=123" first. He then wants to set the options to "resend_igmp=10" instead. 17:18 < osvoboda> What he ends up with is "miimon=123 resend_igmp=10", not just "resend_igmp=10". 17:22 < osvoboda> There are multiple solutions to this: creating a GUI which would treat bonding options individually. The user would "reset" miimon to 0 manually, if he wanted. 17:23 -!- shaohef: has quit [Remote host closed the connection] 17:23 < osvoboda> Or just refusing to change any options when a bond is used. 17:23 < osvoboda> So the user would not get these unexpected results. 17:24 < osvoboda> The third is to use my resetting code. 17:25 < celebdor> osvoboda: the UI doesn't clear what you previously set 17:25 < osvoboda> Which might be a little racy if there was some other process (apart from VDSM) touching the options, but I guess this is not supported. 17:25 < celebdor> the user after having set miimon=123 17:25 < celebdor> would open the dialog 17:26 < celebdor> and then there's two options 17:26 < celebdor> if he wants a mixture of both 17:26 < celebdor> he should leave the original and add 17:26 < celebdor> if he wants only the second 17:26 < celebdor> just the second should be entered 17:26 < celebdor> and if there are no other users to the bond, that is what will happen 17:27 < osvoboda> celebdor: If there are other users though... 17:28 < celebdor> well, if there are other users then we should probably reset the options so only the new is set 17:29 < osvoboda> Yep. If the user wanted only the second option he would have to enter "miimon=0 resend_igmp=10", so resetting is a must is we do not want to confuse people. 17:31 < celebdor> osvoboda: well, actually 17:32 < celebdor> osvoboda: I think it is easier than that to solve 17:32 < celebdor> we know what has been configured 17:32 < celebdor> if an option is not sent anymore we can just reset that one 17:34 -!- sbonazzo: has quit [Quit: Leaving.] 17:34 -!- osvoboda: has quit [Ping timeout: 252 seconds] 17:37 -!- osvoboda (osvoboda): has joined #vdsm 17:39 < osvoboda> celebdor, danken: Firefox ate all memory again :-/ Can you please resend what you wrote? 17:40 < celebdor> osvoboda: I wrote that we just need to reset those parameters that we have currently configured in the device (which we know from 'cfg' and also from 'runningconfig') that do not come anymore 17:44 < osvoboda> celebdor: Resetting (or applying options) must be carried carefully. In my code, I first deal with the old options, then change the mode, and finally I apply the new options. 17:45 < osvoboda> celebdor: If we just reset everything to default, we could trigger errors, as I wrote to danken. 17:45 < celebdor> osvoboda: but when chaning the mode we are removing the bond 17:45 < celebdor> so we don't need to care about resetting in that case 17:45 < celebdor> as for the other 17:46 < osvoboda> celebdor: Are we though? 17:46 < celebdor> osvoboda: yup 17:46 < celebdor> it should be added to editbonding as I suggested above 17:46 < osvoboda> I must have missed that. 17:46 < osvoboda> Oh. 17:46 < celebdor> after that it will be on both flows 17:49 < osvoboda> celebdor: Can I please ask you to take care of this? All I can do now is just refine my patch to have a good commit message. Next Friday, I have the state examination so I have to revise, prepare a presentation and stuff. 17:50 < celebdor> osvoboda: ok 17:50 < celebdor> I'll do the editbonding fix 17:50 < celebdor> if you need me to handle anything else 17:50 < celebdor> send me an email with the patches and what 17:53 < osvoboda> celebdor: Thanks a lot :-) 17:53 < osvoboda> First I will prepare the patch using bond5 in tests for a push. 17:55 -!- bala2: has quit [Ping timeout: 265 seconds] 18:00 * celebdor is fucking dense 18:00 < celebdor> tbf was working alright 18:00 < celebdor> it was reporting 28-30mbit/s 18:00 < celebdor> and I was demanding 4mbyte/s 18:00 < celebdor> so it's about fine 18:01 < celebdor> fromani: danken: ^^ Ain't it funny how an application reporting in the same line for different attributes bytes and bits can mess with one's brain? 18:02 < fromani> celebdor: one character can make so much difference :) 18:02 < fromani> well two actually (bit vs byte) :P 18:02 < celebdor> indeed 18:02 < celebdor> look at the output 18:03 < celebdor> rhel65_01 qos_testing # iperf -c 192.168.10.2 -t 30 -i 5s -p 10010 18:03 < celebdor> ------------------------------------------------------------ 18:03 < celebdor> Client connecting to 192.168.10.2, TCP port 10010 18:03 < celebdor> TCP window size: 19.3 KByte (default) 18:03 < celebdor> ------------------------------------------------------------ 18:03 < celebdor>: local 192.168.10.1 port 52652 connected with 192.168.10.2 port 10010 18:03 < celebdor>: Interval Transfer Bandwidth 18:03 < celebdor>: 0.0- 5.0 sec 18.2 MBytes 30.6 Mbits/sec 18:03 < celebdor>: 5.0-10.0 sec 18.5 MBytes 31.0 Mbits/sec 18:03 < celebdor>: 10.0-15.0 sec 19.0 MBytes 31.9 Mbits/sec 18:03 < celebdor>: 15.0-20.0 sec 18.9 MBytes 31.7 Mbits/sec 18:03 < celebdor>: 20.0-25.0 sec 18.9 MBytes 31.7 Mbits/sec 18:03 < celebdor>: 25.0-30.0 sec 18.6 MBytes 31.2 Mbits/sec 18:03 < celebdor>: 0.0-30.1 sec 112 MBytes 31.3 Mbits/sec 18:03 < celebdor> fromani: my brain saw mbytes in the transfer column and copied it over to the bandwidth column 18:03 * celebdor is a dunce 18:06 -!- fabiand (Fabian Deutsch): has joined #vdsm 18:16 -!- #vdsm,#theforeman,#theforeman-dev ybronhei: has quit [Ping timeout: 258 seconds] 18:19 -!- nsoffer (Nir Soffer): has joined #vdsm 18:20 < osvoboda> fsimonce: "volume: unify cow format check on creation" results in a compile error on my RHEL6.5. "volume.BLANK_UUID" and "volume.COW_FORMAT" cause this. They should be unprefixed as they are now in volume.py. I do not understand why Jenkins missed this. 18:22 -!- ybronhei (purple): has joined #vdsm 18:23 < osvoboda> danken: ^^ 18:25 < osvoboda> danken: I would love pyflakes to be run before unit tests, BTW. 18:43 -!- fromani: has quit [Quit: Leaving] 18:48 -!- timothy: has quit [Ping timeout: 255 seconds] 18:49 <@danken> osvoboda: it makes sense - please send a patch reversing that order. 18:50 <@danken> osvoboda: and a fix for the specific pyflakes glitch would be nice 18:56 -!- alitke: has quit [Quit: Leaving] 18:57 -!- danken: has quit [Quit: Leaving.] 19:01 -!- alitke (Adam Litke): has joined #vdsm 19:14 -!- osvoboda is now known as osvoboda_away 19:24 -!- timothy (Timothy Asir): has joined #vdsm 19:25 -!- #vdsm fsimonce: has quit [Quit: Coyote finally caught me] 19:25 -!- nsoffer: has quit [Ping timeout: 252 seconds] 19:30 -!- kobi (Kobi Ianko): has joined #vdsm 19:52 -!- kobi: has quit [Ping timeout: 276 seconds] 19:52 -!- xfrancis: has quit [Ping timeout: 252 seconds] 19:55 -!- nsoffer (Nir Soffer): has joined #vdsm 19:57 -!- timothy: has quit [Remote host closed the connection] 20:02 -!- bazulay: has quit [Quit: Leaving.] 20:25 -!- nsoffer: has quit [Ping timeout: 240 seconds] 20:26 -!- osvoboda_away is now known as osvoboda 20:53 -!- osvoboda is now known as osvoboda_away 21:00 -!- kobi (Kobi Ianko): has joined #vdsm 21:36 -!- kobi: has quit [Ping timeout: 264 seconds] 21:48 -!- kobi (Kobi Ianko): has joined #vdsm 21:54 -!- AlbertoSilva (AlbertoSilva): has joined #vdsm 22:13 -!- fabiand: has quit [Quit: Verlassend] 22:27 -!- osvoboda_away is now known as osvoboda 22:28 -!- kobi: has quit [Ping timeout: 265 seconds] 22:49 -!- osvoboda is now known as osvoboda_away 22:51 -!- apahim: has quit [Quit: Leaving] 23:10 -!- osvoboda_away is now known as osvoboda 23:12 -!- rmatinata: has quit [Ping timeout: 240 seconds] 23:21 -!- osvoboda: has quit [Quit: ChatZilla 0.9.90.1 [Firefox 29.0.1/20140514164129]] 23:25 -!- fabiand (Fabian Deutsch): has joined #vdsm 23:26 -!- moolit (purple): has joined #vdsm 23:36 -!- xfrancis (Xavi Francisco): has joined #vdsm --- Log closed Sat May 31 00:00:25 2014