--- Log opened wo sep 17 00:00:22 2014 00:01 -!- fpliger: has quit [Ping timeout: 255 seconds] 00:26 -!- adahms (Andrew Dahms): has joined #vdsm 00:26 -!- rmatinata (Ricardo Marin Matinata): has joined #vdsm 00:43 -!- nsoffer: has quit [Ping timeout: 272 seconds] 01:40 -!- shaohef1 (shaohef): has joined #vdsm 01:41 -!- shaohef: has quit [Ping timeout: 260 seconds] 01:45 -!- nsoffer (Nir Soffer): has joined #vdsm 02:06 -!- nsoffer: has quit [Read error: Connection reset by peer] 02:08 -!- nsoffer (Nir Soffer): has joined #vdsm 02:23 -!- nsoffer: has quit [Read error: Connection reset by peer] 02:37 -!- bala: has quit [Read error: Connection reset by peer] 03:38 -!- gpadgett: has quit [Ping timeout: 258 seconds] 03:48 -!- Netsplit *.net <-> *.split quits: mskrivanek_away, adahms 03:49 -!- mliu (purple): has joined #vdsm 03:49 -!- mliu: has left #vdsm [] 03:53 -!- adahms (Andrew Dahms): has joined #vdsm 03:54 -!- mskrivanek_away (mskrivan): has joined #vdsm 05:25 -!- adahms_ (Andrew Dahms): has joined #vdsm 05:27 -!- adahms: has quit [Ping timeout: 272 seconds] 05:38 -!- shaohef1: has quit [Ping timeout: 272 seconds] 05:43 -!- shaohef (shaohef): has joined #vdsm 06:42 -!- xaviern (Xavier): has joined #vdsm 06:50 -!- shaohef: has quit [Read error: Connection reset by peer] 06:57 -!- #vdsm xaviern: has quit [Ping timeout: 255 seconds] 07:12 -!- fabiand (Fabian Deutsch): has joined #vdsm 07:14 -!- ibarkan_ (ibarkan): has joined #vdsm 07:16 -!- xaviern (Xavier): has joined #vdsm 07:20 -!- fpliger (fpliger): has joined #vdsm 07:24 -!- Humble (Humble Chirammal): has joined #vdsm 07:26 -!- #vdsm xaviern: has quit [Quit: WeeChat 0.4.3] 07:27 -!- xaviern (Xavier): has joined #vdsm 07:31 -!- ishaby (Idan Shaby): has joined #vdsm 07:36 -!- sbonazzo (purple): has joined #vdsm 07:36 -!- aravindavk (Aravinda): has joined #vdsm 07:46 -!- #vdsm ybronhei: has quit [Ping timeout: 240 seconds] 08:12 -!- apuimedo (antoni): has joined #vdsm 08:22 -!- bala: has quit [Quit: Leaving.] 08:34 -!- fromani (Francesco Romani): has joined #vdsm 08:35 -!- apuimedo: has quit [Quit: WeeChat 0.4.3] 08:35 -!- apuimedo (antoni): has joined #vdsm 08:38 -!- shaohef (shaohef): has joined #vdsm 08:39 -!- ibarkan_: has quit [Quit: Konversation terminated!] 08:40 -!- ibarkan (ibarkan): has joined #vdsm 08:42 -!- shaohef: has quit [Ping timeout: 246 seconds] 08:43 -!- pkliczew (Piotr Kliczewski): has joined #vdsm 08:44 -!- ybronhei (purple): has joined #vdsm 08:45 -!- timothy (Timothy Asir): has joined #vdsm 08:46 -!- timothy is now known as Guest53139 08:46 -!- shaohef (shaohef): has joined #vdsm 08:52 -!- acanan (Aharon Canan): has joined #vdsm 08:57 -!- phoracek (phoracek): has joined #vdsm 09:06 -!- aravindavk: has quit [Ping timeout: 260 seconds] 09:17 -!- adahms_: has quit [Quit: Leaving] 09:17 -!- shaohef: has quit [Quit: Leaving.] 09:18 -!- shaohef (shaohef): has joined #vdsm 09:22 -!- aravindavk (Aravinda): has joined #vdsm 09:26 -!- shaohef: has quit [Ping timeout: 272 seconds] 09:41 -!- phoracek: has quit [Quit: WeeChat 0.4.3] 09:46 -!- shaohef (shaohef): has joined #vdsm 09:55 -!- mode/#vdsm: by ChanServ 09:55 -!- danken (purple): has joined #vdsm 09:56 <@danken> pkliczew: coul dyou state the nature of your verification of http://gerrit.ovirt.org/#/c/32985/2..3/vdsm/protocoldetector.py ? 09:56 < pkliczew> danken, sure 09:56 <@danken> We need to add a functional test for this case (a broken client) 09:57 < pkliczew> danken, we already have ssl related tests which test broken client scenarios 09:57 <@danken> pkliczew: something simple, that start a TCP connection, and then disappears 09:57 < pkliczew> danken, it is sslutils test 09:58 <@danken> pkliczew: but they did not catch this issue 09:58 < pkliczew> danken, because those tests are on ssl level not detection level 09:58 <@danken> which is why we need a functional test - that tests all levels 09:59 < pkliczew> danken, ok will add 10:00 -!- shaohef: has quit [Quit: Leaving.] 10:01 -!- fpliger: has quit [Remote host closed the connection] 10:02 -!- fpliger (fpliger): has joined #vdsm 10:04 -!- shaohef (shaohef): has joined #vdsm 10:05 -!- gvallarelli (giuseppe): has joined #vdsm 10:10 -!- phoracek (phoracek): has joined #vdsm 10:15 -!- aravindavk: has quit [Ping timeout: 246 seconds] 10:26 -!- aravindavk (Aravinda): has joined #vdsm 10:27 -!- danken: has quit [Ping timeout: 245 seconds] 10:36 -!- mode/#vdsm: by ChanServ 10:36 -!- danken (purple): has joined #vdsm 10:44 -!- derez_ (Daniel Erez): has joined #vdsm 10:47 -!- aravindavk: has quit [Quit: Leaving] 10:47 -!- nsoffer (Nir Soffer): has joined #vdsm 10:47 -!- aravindavk (Aravinda): has joined #vdsm 10:59 -!- mpolednik (Martin Polednik): has joined #vdsm 11:00 -!- moolit (purple): has joined #vdsm 11:07 -!- shaohef: has quit [Quit: Leaving.] 11:15 -!- shaohef (shaohef): has joined #vdsm 11:26 -!- moolit: has quit [Ping timeout: 272 seconds] 11:38 -!- apuimedo: has quit [Ping timeout: 245 seconds] 11:46 -!- sbonazzo is now known as sbonazzo|afk 11:56 -!- mpolednik: has quit [Ping timeout: 260 seconds] 12:11 -!- nsoffer: has quit [Read error: Connection reset by peer] 12:12 < phoracek> danken: i've just verified Emergency patch http://gerrit.ovirt.org/#/c/31336/ (finally) 12:14 -!- nsoffer (Nir Soffer): has joined #vdsm 12:14 <@danken> phoracek: thanks. but please say - on gerrit - HOW you verified 12:15 -!- sbonazzo|afk is now known as sbonazzo 12:15 -!- bazulay (purple): has joined #vdsm 12:22 -!- phoracek: has quit [Quit: WeeChat 0.4.3] 12:28 -!- nsoffer: has quit [Read error: Connection reset by peer] 12:28 -!- moolit (purple): has joined #vdsm 12:31 -!- fpliger: has quit [Ping timeout: 245 seconds] 12:31 -!- fpliger (fpliger): has joined #vdsm 12:49 -!- adahms (Andrew Dahms): has joined #vdsm 12:55 < pkliczew> msivak_, ping 12:55 < msivak_> pkliczew: pong 12:56 < pkliczew> msivak_, where can I find logs which help me to understand where I misconfigured my optimizer setup 12:56 < pkliczew> msivak_, I can see Status: Data refresh failed: undefined in the tab 12:57 < msivak_> pkliczew: undefined? interesting 12:57 < msivak_> pkliczew: the javascript console in the browser has some logs 12:58 < msivak_> and server logs depend on what you used at the backend 12:58 < pkliczew> msivak_, I use jetty 12:58 < pkliczew> msivak_, will check 12:59 -!- shaohef: has quit [Quit: Leaving.] 13:04 -!- shaohef (shaohef): has joined #vdsm 13:06 -!- bazulay: has quit [Quit: Leaving.] 13:06 -!- bazulay (purple): has joined #vdsm 13:08 -!- danken: has quit [Ping timeout: 245 seconds] 13:08 -!- mode/#vdsm: by ChanServ 13:08 -!- danken (purple): has joined #vdsm 13:17 -!- vered: has quit [Ping timeout: 258 seconds] 13:31 -!- shaohef: has quit [Remote host closed the connection] 13:31 -!- fpliger: has quit [Remote host closed the connection] 13:32 -!- fpliger (fpliger): has joined #vdsm 13:39 < fromani> nice to see ioprocess logs are improved 13:39 < fromani> however, for my own taste, five lines for each operation is still a bit too much. For example: Thread-19::DEBUG::2014-09-17 13:38:49,746::__init__::232::IOProcess::(_processLogs) Receiving request... 13:39 < fromani> Thread-19::DEBUG::2014-09-17 13:38:49,746::__init__::232::IOProcess::(_processLogs) Queuing request in the thread pool... 13:39 < fromani> Thread-19::DEBUG::2014-09-17 13:38:49,746::__init__::232::IOProcess::(_processLogs) Extracting request information... 13:39 < fromani> Thread-19::DEBUG::2014-09-17 13:38:49,746::__init__::232::IOProcess::(_processLogs) (59978) Got request for method 'access' 13:39 < fromani> Thread-19::DEBUG::2014-09-17 13:38:49,746::__init__::232::IOProcess::(_processLogs) (59978) Queuing response 13:39 < fromani> worth file a bug about that? 13:40 < fromani> danken: what do you think? ^^^^ 13:41 < fromani> maybe just move them in a separate log, like /var/log/vdsm/ioprocess.log 13:41 -!- phoracek (phoracek): has joined #vdsm 13:57 -!- Guest53139: has quit [Remote host closed the connection] 13:58 -!- phoracek: has quit [Ping timeout: 258 seconds] 13:58 -!- fpliger: has quit [Remote host closed the connection] 13:58 -!- fpliger (fpliger): has joined #vdsm 14:04 -!- phoracek (phoracek): has joined #vdsm 14:11 -!- bazulay: has quit [Ping timeout: 272 seconds] 14:13 -!- aravindavk: has quit [Quit: Leaving] 14:24 -!- bazulay (purple): has joined #vdsm 14:29 -!- nsoffer (Nir Soffer): has joined #vdsm 14:39 -!- acanan: has quit [Remote host closed the connection] 14:45 -!- fpliger: has quit [Remote host closed the connection] 14:45 -!- fpliger (fpliger): has joined #vdsm 14:48 -!- phoracek: has quit [Quit: WeeChat 0.4.3] 15:07 -!- nsoffer: has quit [Ping timeout: 240 seconds] 15:10 -!- bazulay: has quit [Ping timeout: 260 seconds] 15:13 -!- bazulay (purple): has joined #vdsm 15:22 -!- gpadgett (Greg Padgett): has joined #vdsm 15:22 -!- nsoffer (Nir Soffer): has joined #vdsm 15:34 -!- #vdsm xaviern: has quit [Ping timeout: 272 seconds] 15:37 -!- adahms: has quit [Quit: Leaving] 15:50 -!- fpliger: has quit [Remote host closed the connection] 15:50 -!- fpliger (fpliger): has joined #vdsm 15:53 -!- xaviern (Xavier): has joined #vdsm 16:04 -!- ibarkan: has quit [Ping timeout: 255 seconds] 16:10 -!- #vdsm xaviern: has quit [Ping timeout: 240 seconds] 16:17 -!- #vdsm dougsland: has quit [Ping timeout: 250 seconds] 16:24 -!- bazulay: has quit [Quit: Leaving.] 16:25 -!- bazulay (purple): has joined #vdsm 16:25 -!- rmatinata: has quit [Ping timeout: 272 seconds] 16:25 -!- nsoffer: has quit [Ping timeout: 246 seconds] 16:27 -!- apahim (Amador Pahim): has joined #vdsm 16:40 < pkliczew> danken, can you please take a look at -> http://ur1.ca/i7e6g 16:41 < pkliczew> danken, not sure who to ask about it 16:42 < pkliczew> ybronhei, ^^ 16:43 < ybronhei> now you sure :) 16:43 < ybronhei> maybe check libvirt log 16:43 < ybronhei> and vdsm might say something relevant 16:45 < pkliczew> i do not see anything in libvirt log 16:50 -!- dougsland (Douglas): has joined #vdsm 16:55 < fromani> pkliczew: hi, there is a way to force an host to use xml-rpc again? I'm asking because I'd like to do a comparison 16:56 < pkliczew> fromani, yes, when the host in maintenance you can edit and change the protocol 16:56 < fromani> pkliczew: cool, trying 16:56 < pkliczew> fabiand, when activated it will use changed protocol 16:57 -!- bala: has quit [Quit: Leaving.] 16:57 <@danken> pkliczew: is it migration destination, or plain startup? 16:57 < fromani> pkliczew: got it thanks a lot 16:57 <@danken> do you have something interesting on libvirt logs (particularly, /var/log/libvirt/qemu/.log 16:57 <@danken> ) 16:58 < fabiand> pkliczew, oh --- sorry? :) 16:58 < fromani> fabiand: probably was for me :) 16:58 <@danken> pkliczew: you get this error when qemu dies under libvirt 16:58 < pkliczew> danken, only information starting up, some params, shuting down 16:58 < pkliczew> danken, nothing else 16:59 < fabiand> fromani, ;) 16:59 -!- nsoffer (Nir Soffer): has joined #vdsm 17:00 < pkliczew> danken, is there a way to recover? 17:00 < pkliczew> danken, engine thinks that the host is OK 17:01 < pkliczew> danken, wouldn't be good to notify engine about issue like that, the host is not operational 17:02 <@danken> pkliczew: well, it may be a very specific problem with a very specific VM 17:02 < pkliczew> danken, I tried to run a vm using virt-manager and get the same info 17:03 <@danken> Engine can be smarter and not try to run a VM after 3 repeated failures 17:03 < fromani> pkliczew: anything relevant on /var/log/libvirt/libvirtd.log? 17:03 * fromani feels that QEMU logs are *way* too terse 17:03 < pkliczew> danken, sure 17:04 < pkliczew> fromani, nothing there starting up and shuting down 17:04 < pkliczew> fromani, nothing else 17:04 <@danken> pkliczew: could you share libvirtd.log and qemu logs? maybe you missed something? 17:04 < pkliczew> sure 17:04 < fromani> pkliczew: have you by any chance recently changed the config of libvirt? and by "recently" I mean "minutes ago" :) 17:05 < pkliczew> fromani, no 17:05 < fromani> pkliczew: then I don't know... 17:07 < pkliczew> danken, where should I upload the logs? 17:09 < pkliczew> danken, fromani https://drive.google.com/file/d/0ByDkUDLXsT0YOVJsZldmekY3U1U/edit?usp=sharing 17:12 -!- sbonazzo: has quit [Quit: Leaving.] 17:12 -!- ishaby: has quit [Ping timeout: 260 seconds] 17:13 -!- derez_: has quit [Quit: Leaving] 17:15 -!- phoracek (phoracek): has joined #vdsm 17:19 -!- bazulay: has quit [Ping timeout: 245 seconds] 17:19 -!- derez_ (Daniel Erez): has joined #vdsm 17:20 < fromani> pkliczew: looking 17:21 -!- rmatinata (Ricardo Marin Matinata): has joined #vdsm 17:23 <@danken> 2014-09-17 07:36:13.719+0000: 3934: error : virPidFileAcquirePath:410 : Failed to acquire pid file '/var/run/libvirtd.pid': Resource temporarily unavailable 17:23 <@danken> pkliczew: seems like a stale libvirt process lurking out there 17:23 <@danken> can you lsof that lock file? 17:24 <@danken> pkliczew: I've seen this issue before, and we lacked a reproducer 17:24 <@danken> please go to #virt, and ask libvirt guys to take a look 17:24 < pkliczew> danken, my host is up and running, give me some time and I will let you ssh to it 17:24 <@danken> it seems like an ugly bug 17:25 -!- fpliger: has quit [Remote host closed the connection] 17:25 <@danken> your libvirt log has not ref of virDomainCreateXML 17:25 <@danken> verry odd pkliczew... 17:25 < pkliczew> hmm 17:25 -!- fpliger (fpliger): has joined #vdsm 17:26 < pkliczew> danken, I was configuring optaplanner so I haven't touched this machine for a while 17:26 < pkliczew> danken, and I wanted to create vms with it I noticed this behavior 17:26 -!- danken is now known as danken_afk 17:27 -!- pkliczew_ (Piotr Kliczewski): has joined #vdsm 17:27 -!- pkliczew_: has quit [Client Quit] 17:28 < pkliczew> danken_afk, on which server I can find #virt 17:28 -!- gvallarelli: has quit [Quit: Leaving] 17:29 -!- fpliger: has quit [Remote host closed the connection] 17:29 -!- fpliger (fpliger): has joined #vdsm 17:35 < fromani> pkliczew: internal RH IRC server 17:35 < pkliczew> fromani, thanks 17:35 < fromani> pkliczew: maybe on OFTC is good as well 17:37 -!- phoracek: has quit [Quit: WeeChat 0.4.3] 17:38 < pkliczew> fromani, I sent general message let's see whether anyone will answer 17:38 -!- phoracek (phoracek): has joined #vdsm 17:39 < pkliczew> fromani, do you know anyone who should I ask directly? 17:39 < fromani> pkliczew: well yes and no because I usually ping specific people when I do have specific questions, not generic one like that one 17:39 < pkliczew> fromani, ok 17:40 < fromani> pkliczew: for the sake of completeness, most of time I talked with mprivozn or pkrempa , but again for specific things 17:40 < pkliczew> fromani, sure thanks 17:40 < fromani> pkliczew: np 17:46 < alitke__> grr, seems jsonrpc is causing flakiness in the live snapshot creation flows too :( 17:47 * alitke__ puts a sticky note on his monitor to remind him that step 1 of every bug triage is to disable jsonrpc and see if the problem goes away 17:47 < pkliczew> alitke__, any logs? 17:47 < alitke__> yeah, but I can't see anything in there about it. 17:47 < pkliczew> alitke__, hmm 17:47 < alitke__> seems that sometimes the snapshot call from engine is being lost 17:48 < alitke__> It's really hard to create a decent bug report for all of these. 17:49 < alitke__> for me, jsonrpc hosts just act generally flaky and it's hard to nail down the specific problem. 17:49 < pkliczew> alitke__, please send me vdsm log I will take a look 17:49 < fromani> alitke__: interesting thing you just said. I saw something similar here but (as reported on mail) I thought it was just my environment being messy... now I'll reevaluate and keep a closer eye. 17:50 < alitke__> yeah, someone was trying to test live merge and we couldn't even reliably produce snapshots. 17:50 < fromani> alitke__: pkliczew I don't have specific incidents to report, but just a few times I clicked on engine UI and nothing arrived to VDSM, apparently 17:51 < pkliczew> fromani, anything in the engine log? 17:51 < fromani> pkliczew: let's see 17:51 < alitke__> pkliczew, sent 17:51 < alitke__> I sent you an engine log and vdsm log 17:52 < pkliczew> alitke__, thank I will take a look 17:53 < pkliczew> alitke__, anything in particular that I should look for? 17:53 < pkliczew> alitke__, what is the verb that you are trying to execute? 17:54 < alitke__> VM.snapshot and VM.merge 17:54 < fromani> pkliczew: the only vaguely relevant trail I can find is there: http://fpaste.org/134263/ 17:54 < fromani> pkliczew: I believe is still too vague information, I'll make a note to pay more attention and file a proper BZ in case it happens again 17:54 < alitke__> oh yeah, I was seeing some timeouts too 17:55 < alitke__> the vdsm log is now so noisy it's hard to pick up meaningful information. 17:56 < pkliczew> alitke__, logs from IOprocess :) 17:57 < alitke__> yeah and jsonrpc 17:57 < alitke__> xmlrpc used to have one entry for the call and one for the return 17:57 < alitke__> now it's a 'bit' more verbose than that :) 17:57 < fromani> to be fair, what puzzles me most is ioprocess... five lines for each operation seems too much for me 17:58 < fromani> I'm more and more persuaded that a separate /var/log/vdsm/ioprocess.log would make more sense 17:58 < pkliczew> alitke__, I do not see any issues in vdsm log, there were some issue but all fixed now so if you could update the engine most of the issues will go away 17:59 < alitke__> ok. I am debugging on someone else's setup so will encourage them to update. 17:59 < alitke__> is ovirt-3.5-pre new enough 18:01 < pkliczew> alitke__, this one seems like a bug: http://ur1.ca/i7eda 18:02 < alitke__> I'll let gpadgett know 18:04 < gpadgett> alitke__: pkliczew: this patch will help: http://gerrit.ovirt.org/#/c/32960/3 18:13 -!- apuimedo (antoni): has joined #vdsm 18:16 -!- derez_: has quit [Ping timeout: 245 seconds] 18:21 < pkliczew> danken_afk, fromani it seems like ssh process died. it is spawn by libvirt 18:22 -!- fpliger: has quit [Ping timeout: 260 seconds] 18:32 -!- phoracek: has quit [Quit: WeeChat 0.4.3] 18:35 -!- fpliger (fpliger): has joined #vdsm 18:35 -!- fpliger: has quit [Remote host closed the connection] 18:39 -!- pkliczew: has quit [Ping timeout: 260 seconds] 18:53 -!- ishaby (Idan Shaby): has joined #vdsm 18:55 -!- fabiand: has quit [Quit: Verlassend] 18:56 -!- ishaby: has quit [Client Quit] 19:00 -!- Netsplit *.net <-> *.split quits: moolit, Humble 19:00 -!- Netsplit over, joins: moolit, Humble 19:02 -!- Netsplit *.net <-> *.split quits: fromani, rmatinata 19:03 -!- Netsplit over, joins: rmatinata, fromani 19:06 -!- orc_emac1 ("First Av orc_emac"): has joined #vdsm 19:08 -!- orc_emac: has quit [Ping timeout: 250 seconds] 19:09 -!- orc_emac1 is now known as orc_emac 19:17 -!- ishaby (Idan Shaby): has joined #vdsm 19:31 -!- moolit: has quit [Ping timeout: 258 seconds] 19:32 -!- #vdsm ybronhei: has quit [Ping timeout: 260 seconds] 19:49 -!- fpliger (fpliger): has joined #vdsm 19:53 -!- ishaby: has quit [Quit: Leaving] 19:58 -!- phoracek (phoracek): has joined #vdsm 20:07 -!- fpliger: has quit [Remote host closed the connection] 20:08 -!- fpliger (fpliger): has joined #vdsm 20:09 -!- bazulay (purple): has joined #vdsm 20:12 -!- fpliger: has quit [Ping timeout: 255 seconds] 20:30 -!- apuimedo is now known as apuimedo|away 21:19 -!- fpliger (fpliger): has joined #vdsm 21:23 -!- ibarkan (ibarkan): has joined #vdsm 21:33 < nsoffer> danken_afk, can you check http://gerrit.ovirt.org/32884 ? 21:34 -!- dyasny (Dan Yasny): has joined #vdsm 21:50 -!- #vdsm dyasny: has quit [Quit: Ex-Chat] 21:58 -!- dyasny (Dan Yasny): has joined #vdsm 22:01 -!- ibarkan: has quit [Ping timeout: 272 seconds] 22:40 -!- vered: has quit [Ping timeout: 245 seconds] 22:51 -!- fpliger: has quit [Remote host closed the connection] 22:52 -!- fpliger (fpliger): has joined #vdsm 22:54 -!- phoracek: has quit [Quit: WeeChat 0.4.3] 22:56 -!- fpliger: has quit [Ping timeout: 245 seconds] 22:59 -!- rmatinata: has quit [Ping timeout: 255 seconds] 23:04 <@danken_afk> nsoffer: yep fine. 23:04 <@danken_afk> nsoffer: the qemu-img non-compat is a mess 23:05 -!- #vdsm dyasny: has quit [Ping timeout: 272 seconds] 23:05 < nsoffer> danken_afk, indeed 23:05 < nsoffer> danken_afk, lets drop qemu and use something else :-) 23:05 <@danken_afk> nsoffer: I'm sure we're not the only app using `qemu-img create qcow2` directly 23:06 -!- danken_afk is now known as danken 23:06 < nsoffer> danken, we do now exactly what libvirt does 23:06 <@danken> nsoffer: yeah, but I'm thinking of OTHER apps 23:06 < nsoffer> danken, this is what kwolf is recommending - see the bug 23:06 <@danken> that like us, does not use libvirt to shield them of changes like this 23:07 < nsoffer> danken, well they will have to use similar checks 23:07 < nsoffer> danken, or version checks, which are more fragile 23:08 <@danken> nsoffer: or qemu-img could keep it's f*ing default. 23:08 < nsoffer> danken, it must keep the old format as default 23:09 < nsoffer> danken, this is what they told us when we tried to explain this: 23:09 < nsoffer> "Yes, this kind of change is unavoidable. We can't leave all new features 23:09 < nsoffer> disabled and give users a crappy qemu by default." 23:11 <@danken> I wonder which other changes like this lurk there 23:11 < nsoffer> btw - this is the same on fedora 20 23:11 < nsoffer> I did not check, but I guess also on 19 23:12 < apuimedo|away> danken: why are we checking for distro in http://gerrit.ovirt.org/#/c/33021/1/vdsm.spec.in,cm 23:12 < apuimedo|away> instead of just checking for having systemd? 23:12 -!- apuimedo|away is now known as apuimedo 23:16 <@danken> nsoffer: they should have done `repoquery -a --whatrequires qemu-img` and notified all user of this change 23:16 -!- ybronhei (purple): has joined #vdsm 23:17 < nsoffer> nice 23:17 < nsoffer> ok, on fedora 19 - qemu supports the -o compat option 23:18 < nsoffer> but you cannot know what is the image format, since qemu-img info does not tell you 23:18 <@danken> apuimedo: basically, since we're lazy. but in %systemd_post is something related to rpm version, not to existence of systemd 23:18 < nsoffer> So again, a basic feature is broken in upstream, and we find it only when testing rhel7 23:19 <@danken> "with_tmpfiles_macro" is plain stupid name. 23:19 <@danken> sohuld have been with_tmpfiles 23:19 < apuimedo> also 23:20 <@danken> nsoffer: no one tried to mix and match f19 and el6 in a single datacenter 23:20 < apuimedo> danken: I tried 23:20 < apuimedo> without success :( 23:20 <@danken> apuimedo: f19 and el6? 23:20 < apuimedo> yeah 23:20 < apuimedo> once I managed to overcome the pc versions with some trick 23:21 <@danken> apuimedo: whar was the failure? 23:21 < apuimedo> but I lost the link to the trick 23:21 < apuimedo> xD 23:21 < apuimedo> so I couldn't try it again 23:21 <@danken> ah, not the same cluster, that's intentionally not supported 23:21 <@danken> but for them to share storage 23:21 <@danken> that should have worked 23:21 <@danken> but never tested, and hence - does not. 23:22 < apuimedo> well, I can try it easily 23:22 < apuimedo> ;-) 23:22 < apuimedo> f20 plus el6 23:22 < apuimedo> what fails? 23:22 < nsoffer> danken, I tried, it does not work 23:22 < nsoffer> you cannot add fedora host to cluster create with el6 host 23:23 < nsoffer> apuimedo, set the f20 machine to be the spm 23:23 <@danken> nsoffer: again, that's fine. but I want to have f20 cluster, and an el6 cluster in the same data center 23:23 < nsoffer> then create vm with a disk 23:24 < nsoffer> and try to run the vm on the el6 machine 23:24 <@danken> apuimedo: we are aware of one failure http://gerrit.ovirt.org/32836 23:24 < nsoffer> then try to create a snapshot 23:24 < apuimedo> ouch 23:24 < apuimedo> ok 23:25 <@danken> nsoffer: now with your patch applied, would such a datacenter fly? 23:25 < nsoffer> it will fly until the next bug :-) 23:25 < nsoffer> 99 bugs on the wall, take one bug... 23:25 < apuimedo> nsoffer: so I should try with http://gerrit.ovirt.org/#/c/32836/ applied? 23:25 < apuimedo> patch it around 23:26 < nsoffer> 98 bugs on the wall 23:26 < apuimedo> and now 117 bugs on the wall! 23:26 < nsoffer> right 23:26 < nsoffer> it works with mixed rhel6 and rhel7 - for some basic flows 23:27 < apuimedo> ok 23:27 < apuimedo> danken: nsoffer is this backported to ovirt-3.5 already? 23:28 < apuimedo> nvmnd 23:28 < apuimedo> found it 23:28 < nsoffer> http://gerrit.ovirt.org/33020 23:29 < nsoffer> but this is not only about mixing 23:29 < nsoffer> it is about the storage format 23:29 < apuimedo> I'm trying it with this one 23:29 < apuimedo> is that right? 23:30 < nsoffer> if you move a storage domain created using fedora/rhel7 to rhel6 cluster, the rhel6 machine cannot use it, since this is not in qcow2 compat=0.10 23:30 < nsoffer> which is our storage domain format v3 23:31 < nsoffer> apuimedo, 33020? 23:31 < apuimedo> yup 23:31 < apuimedo> nsoffer: ^^ 23:31 < nsoffer> hopefully 23:32 < nsoffer> if you try it, please add another verify to the patch 23:34 < nsoffer> danken, "in a different patch: consider using @memoize to save some time." 23:34 < nsoffer> danken, then it will break when qemu is upgraded while vdsm is running 23:35 < nsoffer> danken, unlikely, but we cannot ignore this 23:35 <@danken> nsoffer: I don't think that you evil humor would be understood http://gerrit.ovirt.org/#/c/32928/4//COMMIT_MSG 23:36 < nsoffer> danken, he said "Done" in the previous patchset 23:37 < nsoffer> danken, btw, do you know why he is using "x$foo" = "xbar" 23:37 <@danken> nsoffer: el6->el7 upgrade while vdsm is running?! 23:37 < nsoffer> danken, no, upgrade to qemu version that includes the new format 23:38 < nsoffer> you can never know what will be backported 23:38 <@danken> nsoffer: you KNOW they would not break the default in el6.7. 23:38 <@danken> it's a stable branch 23:39 < nsoffer> lets see :-) 23:39 <@danken> x$bla is just an old idiom 23:39 <@danken> It's needless when you use quotes 23:39 < nsoffer> if you show me a profile with the new code on the top, I will cash it using stat 23:39 <@danken> that you should use anyway 23:41 <@danken> nsoffer: oh, it's humor again. 23:41 < nsoffer> thats what I suggested in the previous patch 23:42 < nsoffer> danken, the profile? 23:42 <@danken> msivak_ could handle it in the morning 23:44 < nsoffer> danken, there was no humor there, I just ask why he is using x 23:47 < nsoffer> danken, did you see this: https://bugzilla.redhat.com/1141658 23:50 < nsoffer> danken, we may have this issue on fedora 19/20 also 23:53 < nsoffer> grepping audit.log on f19 and f20 show many sanlock errors. Need to block access to storage with spm to check this issue 23:59 < apuimedo> I wonder what caused the sudden increase in policy issues --- Log closed do sep 18 00:00:25 2014