- Devel - oVirt List Archives

Fwd: New Defects reported by Coverity Scan for ovirt-engine
by Michal Skrivanek 21 Nov '16

21 Nov '16

--Apple-Mail-D6BD3946-3D96-44AC-A6CA-27DF220B7C24 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Not sure who touched that, but since it's a NPE - Tal, can you doublecheck p= lease? Begin forwarded message: > From: scan-admin(a)coverity.com > Date: 21 November 2016 at 21:13:22 GMT+1 > To: mskrivan(a)redhat.com > Subject: New Defects reported by Coverity Scan for ovirt-engine >=20 >=20 > Hi, >=20 > Please find the latest report on new defect(s) introduced to ovirt-engine f= ound with Coverity Scan. >=20 > 2 new defect(s) introduced to ovirt-engine found with Coverity Scan. > 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the r= ecent build analyzed by Coverity Scan. >=20 > New defect(s) Reported-by: Coverity Scan > Showing 2 of 2 defect(s) >=20 >=20 > ** CID 1366189: Null pointer dereferences (NULL_RETURNS) > /backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vds= broker/vdsbroker/GetDeviceListVDSCommand.java: 112 in org.ovirt.engine.core.= vdsbroker.vdsbroker.GetDeviceListVDSCommand.parseLunFromXmlRpc(java.util.Map= , org.ovirt.engine.core.compat.Version)() >=20 >=20 > __________________________________________________________________________= ______________________________ > *** CID 1366189: Null pointer dereferences (NULL_RETURNS) > /backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vds= broker/vdsbroker/GetDeviceListVDSCommand.java: 112 in org.ovirt.engine.core.= vdsbroker.vdsbroker.GetDeviceListVDSCommand.parseLunFromXmlRpc(java.util.Map= , org.ovirt.engine.core.compat.Version)() > 106 .put(xcon.get(PHYSICAL_DEVICE_FIEL= D).toString(), > 107 DEVICE_ACTIVE_VALUE.equals= (xcon.get(DEVICE_STATE_FIELD).toString())); > 108 } > 109 if (xcon.containsKey(PHYSICAL_DEVICE_FIELD) &&= xcon.containsKey(DEVICE_PATH_CAPACITY_FIELD)) { > 110 // set name and capacity > 111 Long size =3D IrsBrokerCommand.assignLongV= alue(xcon, DEVICE_PATH_CAPACITY_FIELD); >>>> CID 1366189: Null pointer dereferences (NULL_RETURNS) >>>> Unboxing null object "size". > 112 lun.getPathsCapacity() > 113 .put(xcon.get(PHYSICAL_DEVICE_FIEL= D).toString(), > 114 SizeConverter.convert(size= , > 115 SizeConverter.Size= Unit.BYTES, SizeConverter.SizeUnit.GiB).intValue()); > 116 } > 117 } >=20 > ** CID 1366190: Resource leaks (RESOURCE_LEAK) > /backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/stora= ge/CommandsWeightsUtilsTest.java: 37 in org.ovirt.engine.core.bll.storage.Co= mmandsWeightsUtilsTest.adjustWeights(java.util.List, java.util.List, int)() >=20 >=20 > __________________________________________________________________________= ______________________________ > *** CID 1366190: Resource leaks (RESOURCE_LEAK) > /backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/stora= ge/CommandsWeightsUtilsTest.java: 37 in org.ovirt.engine.core.bll.storage.Co= mmandsWeightsUtilsTest.adjustWeights(java.util.List, java.util.List, int)() > 31 adjustWeights(Arrays.<Double> asList(0.33, 0.37, 0.3), Arra= ys.<Integer> asList(3, 3, 4), 10); > 32 } > 33 =20 > 34 public void adjustWeights(List<Double> weightParts, List<Intege= r> expectedWeightsSorted, int totalWeight) { > 35 assertFalse(weightsUtils =3D=3D null); > 36 Map<String, Double> map =3D new HashMap<>(); >>>> CID 1366190: Resource leaks (RESOURCE_LEAK) >>>> Failing to save or close resource created by "java.util.stream.IntSt= ream.range(0, weightParts.size())" leaks it. > 37 IntStream.range(0, weightParts.size()).forEach(i -> map.put= (String.valueOf(i), weightParts.get(i))); > 38 Map<String, Integer> res =3D weightsUtils.adjust(map, total= Weight); > 39 assertEquals("adjusted weights sum should be equal to the t= otal weight", > 40 totalWeight, > 41 res.values().stream().mapToInt(x -> x).sum()); > 42 =20 >=20 >=20 > __________________________________________________________________________= ______________________________ > To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.n= et/wf/click?upn=3D08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRY9v3SZ-2= BLqhn66fucWz5NChdV2QNZzLQCPY1fjqQGlAKjFKQ4pnDnQ8dtAwvCE2G0E-3D_xDvy9aTtFVlNg= NTFLiCVD0cicL2K6Y3d-2BJIBr-2FpAeMq2Gor5C1ZEiQuot3av2-2FBnTXIjnZdjb0Cw-2FiZV5= z3DRotm2ow-2BiwdoVplKeuk7nRFrRXzS4jJb3IZXBSxeZC0bc8KPnuElHCtQryUJ5u-2FY6QjMU= nZuFDu-2BC21coRtHfPr1uF9ZCvkTQAT-2Bg5drHSbNPaszp0YnZzvaUGArGUlXQkPt48dc-2FNZ= aixgGomwsPPQ-3D >=20 > To manage Coverity Scan email notifications for "mskrivan(a)redhat.com", cli= ck https://u2389337.ct.sendgrid.net/wf/click?upn=3D08onrYu34A-2BWcWUl-2F-2Bf= V0V05UPxvVjWch-2Bd2MGckcRbVDbis712qZDP-2FA8y06Nq4QYNJdvz3-2Bo6D7kzKGM4BieGXc= FZeVj8bblbpPZS135zo-2F9pagiHHlVMtL1t-2BQNkdMMpi2fcAFj8yWlY6sxZhzNUWHvSkeP6Ld= DHUGDSs8PI-3D_xDvy9aTtFVlNgNTFLiCVD0cicL2K6Y3d-2BJIBr-2FpAeMq2Gor5C1ZEiQuot3= av2-2FBnYwmACJZZa-2BkRa13JTRgm4K6JnogNoqDZTzNvLRxP6Val1P03EDtJ3QxTG8urJ-2FCT= uXNzEDZ24au9cRqVgy9YVPOiVSvw7tAY4dzssRc8ERmy1mCzlCbU6-2B9s01kYf0EYko6e7QKj2V= pVxVJD8bRNr-2FNXcUSv-2Bu1fA612id1LcCM-3D >=20 --Apple-Mail-D6BD3946-3D96-44AC-A6CA-27DF220B7C24 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+PC9kaXY+ PGRpdj5Ob3Qgc3VyZSB3aG8gdG91Y2hlZCB0aGF0LCBidXQgc2luY2UgaXQncyBhIE5QRSAtIFRh bCwgY2FuIHlvdSBkb3VibGVjaGVjayBwbGVhc2U/PGJyPjxicj48YnI+QmVnaW4gZm9yd2FyZGVk IG1lc3NhZ2U6PGJyPjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxiPkZy b206PC9iPiA8YSBocmVmPSJtYWlsdG86c2Nhbi1hZG1pbkBjb3Zlcml0eS5jb20iPnNjYW4tYWRt aW5AY292ZXJpdHkuY29tPC9hPjxicj48Yj5EYXRlOjwvYj4gMjEgTm92ZW1iZXIgMjAxNiBhdCAy MToxMzoyMiBHTVQrMTxicj48Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzptc2tyaXZhbkByZWRo YXQuY29tIj5tc2tyaXZhbkByZWRoYXQuY29tPC9hPjxicj48Yj5TdWJqZWN0OjwvYj4gPGI+TmV3 IERlZmVjdHMgcmVwb3J0ZWQgYnkgQ292ZXJpdHkgU2NhbiBmb3Igb3ZpcnQtZW5naW5lPC9iPjxi cj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PHNw YW4+PC9zcGFuPjxicj48c3Bhbj5IaSw8L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+ UGxlYXNlIGZpbmQgdGhlIGxhdGVzdCByZXBvcnQgb24gbmV3IGRlZmVjdChzKSBpbnRyb2R1Y2Vk IHRvIG92aXJ0LWVuZ2luZSBmb3VuZCB3aXRoIENvdmVyaXR5IFNjYW4uPC9zcGFuPjxicj48c3Bh bj48L3NwYW4+PGJyPjxzcGFuPjIgbmV3IGRlZmVjdChzKSBpbnRyb2R1Y2VkIHRvIG92aXJ0LWVu Z2luZSBmb3VuZCB3aXRoIENvdmVyaXR5IFNjYW4uPC9zcGFuPjxicj48c3Bhbj4xIGRlZmVjdChz KSwgcmVwb3J0ZWQgYnkgQ292ZXJpdHkgU2NhbiBlYXJsaWVyLCB3ZXJlIG1hcmtlZCBmaXhlZCBp biB0aGUgcmVjZW50IGJ1aWxkIGFuYWx5emVkIGJ5IENvdmVyaXR5IFNjYW4uPC9zcGFuPjxicj48 c3Bhbj48L3NwYW4+PGJyPjxzcGFuPk5ldyBkZWZlY3QocykgUmVwb3J0ZWQtYnk6IENvdmVyaXR5 IFNjYW48L3NwYW4+PGJyPjxzcGFuPlNob3dpbmcgMiBvZiAyIGRlZmVjdChzKTwvc3Bhbj48YnI+ PHNwYW4+PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPioqIENJRCAxMzY2MTg5OiAm bmJzcDtOdWxsIHBvaW50ZXIgZGVyZWZlcmVuY2VzICZuYnNwOyhOVUxMX1JFVFVSTlMpPC9zcGFu Pjxicj48c3Bhbj4vYmFja2VuZC9tYW5hZ2VyL21vZHVsZXMvdmRzYnJva2VyL3NyYy9tYWluL2ph dmEvb3JnL292aXJ0L2VuZ2luZS9jb3JlL3Zkc2Jyb2tlci92ZHNicm9rZXIvR2V0RGV2aWNlTGlz dFZEU0NvbW1hbmQuamF2YTogMTEyIGluIG9yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIu dmRzYnJva2VyLkdldERldmljZUxpc3RWRFNDb21tYW5kLnBhcnNlTHVuRnJvbVhtbFJwYyhqYXZh LnV0aWwuTWFwLCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuY29tcGF0LlZlcnNpb24pKCk8L3NwYW4+ PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+PHNwYW4+KioqIENJ RCAxMzY2MTg5OiAmbmJzcDtOdWxsIHBvaW50ZXIgZGVyZWZlcmVuY2VzICZuYnNwOyhOVUxMX1JF VFVSTlMpPC9zcGFuPjxicj48c3Bhbj4vYmFja2VuZC9tYW5hZ2VyL21vZHVsZXMvdmRzYnJva2Vy L3NyYy9tYWluL2phdmEvb3JnL292aXJ0L2VuZ2luZS9jb3JlL3Zkc2Jyb2tlci92ZHNicm9rZXIv R2V0RGV2aWNlTGlzdFZEU0NvbW1hbmQuamF2YTogMTEyIGluIG9yZy5vdmlydC5lbmdpbmUuY29y ZS52ZHNicm9rZXIudmRzYnJva2VyLkdldERldmljZUxpc3RWRFNDb21tYW5kLnBhcnNlTHVuRnJv bVhtbFJwYyhqYXZhLnV0aWwuTWFwLCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuY29tcGF0LlZlcnNp b24pKCk8L3NwYW4+PGJyPjxzcGFuPjEwNiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsucHV0KHhjb24uZ2V0KFBIWVNJQ0FMX0RFVklDRV9GSUVMRCkudG9TdHJp bmcoKSw8L3NwYW4+PGJyPjxzcGFuPjEwNyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtERVZJQ0VfQUNUSVZFX1ZBTFVFLmVxdWFscyh4Y29uLmdldChERVZJQ0VfU1RBVEVfRklF TEQpLnRvU3RyaW5nKCkpKTs8L3NwYW4+PGJyPjxzcGFuPjEwOCAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDt9PC9zcGFuPjxicj48c3Bhbj4xMDkgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7aWYgKHhjb24uY29udGFpbnNLZXkoUEhZU0lDQUxfREVWSUNFX0ZJRUxEKSAmYW1wOyZh bXA7IHhjb24uY29udGFpbnNLZXkoREVWSUNFX1BBVEhfQ0FQQUNJVFlfRklFTEQpKSB7PC9zcGFu Pjxicj48c3Bhbj4xMTAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Ly8gc2V0IG5hbWUgYW5kIGNhcGFjaXR5PC9zcGFuPjxicj48c3Bhbj4xMTEg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7TG9u ZyBzaXplID0gSXJzQnJva2VyQ29tbWFuZC5hc3NpZ25Mb25nVmFsdWUoeGNvbiwgREVWSUNFX1BB VEhfQ0FQQUNJVFlfRklFTEQpOzwvc3Bhbj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ICZuYnNw OyZuYnNwOyZuYnNwO0NJRCAxMzY2MTg5OiAmbmJzcDtOdWxsIHBvaW50ZXIgZGVyZWZlcmVuY2Vz ICZuYnNwOyhOVUxMX1JFVFVSTlMpPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3Rl PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJj aXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7VW5i b3hpbmcgbnVsbCBvYmplY3QgInNpemUiLjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2tx dW90ZT48L2Jsb2NrcXVvdGU+PHNwYW4+MTEyICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2x1bi5nZXRQYXRoc0NhcGFjaXR5KCk8L3NwYW4+PGJy PjxzcGFuPjExMyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsu cHV0KHhjb24uZ2V0KFBIWVNJQ0FMX0RFVklDRV9GSUVMRCkudG9TdHJpbmcoKSw8L3NwYW4+PGJy PjxzcGFuPjExNCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtTaXplQ29udmVy dGVyLmNvbnZlcnQoc2l6ZSw8L3NwYW4+PGJyPjxzcGFuPjExNSAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtTaXplQ29udmVydGVyLlNpemVVbml0LkJZVEVTLCBTaXplQ29udmVydGVyLlNpemVV bml0LkdpQikuaW50VmFsdWUoKSk7PC9zcGFuPjxicj48c3Bhbj4xMTYgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7fTwvc3Bhbj48YnI+PHNwYW4+MTE3ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO308L3NwYW4+PGJyPjxz cGFuPjwvc3Bhbj48YnI+PHNwYW4+KiogQ0lEIDEzNjYxOTA6ICZuYnNwO1Jlc291cmNlIGxlYWtz ICZuYnNwOyhSRVNPVVJDRV9MRUFLKTwvc3Bhbj48YnI+PHNwYW4+L2JhY2tlbmQvbWFuYWdlci9t b2R1bGVzL2JsbC9zcmMvdGVzdC9qYXZhL29yZy9vdmlydC9lbmdpbmUvY29yZS9ibGwvc3RvcmFn ZS9Db21tYW5kc1dlaWdodHNVdGlsc1Rlc3QuamF2YTogMzcgaW4gb3JnLm92aXJ0LmVuZ2luZS5j b3JlLmJsbC5zdG9yYWdlLkNvbW1hbmRzV2VpZ2h0c1V0aWxzVGVzdC5hZGp1c3RXZWlnaHRzKGph dmEudXRpbC5MaXN0LCBqYXZhLnV0aWwuTGlzdCwgaW50KSgpPC9zcGFuPjxicj48c3Bhbj48L3Nw YW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPjxzcGFuPioqKiBDSUQgMTM2NjE5MDogJm5i c3A7UmVzb3VyY2UgbGVha3MgJm5ic3A7KFJFU09VUkNFX0xFQUspPC9zcGFuPjxicj48c3Bhbj4v YmFja2VuZC9tYW5hZ2VyL21vZHVsZXMvYmxsL3NyYy90ZXN0L2phdmEvb3JnL292aXJ0L2VuZ2lu ZS9jb3JlL2JsbC9zdG9yYWdlL0NvbW1hbmRzV2VpZ2h0c1V0aWxzVGVzdC5qYXZhOiAzNyBpbiBv cmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLnN0b3JhZ2UuQ29tbWFuZHNXZWlnaHRzVXRpbHNUZXN0 LmFkanVzdFdlaWdodHMoamF2YS51dGlsLkxpc3QsIGphdmEudXRpbC5MaXN0LCBpbnQpKCk8L3Nw YW4+PGJyPjxzcGFuPjMxICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2FkanVzdFdlaWdodHMoQXJyYXlzLiZsdDtE b3VibGUmZ3Q7IGFzTGlzdCgwLjMzLCAwLjM3LCAwLjMpLCBBcnJheXMuJmx0O0ludGVnZXImZ3Q7 IGFzTGlzdCgzLCAzLCA0KSwgMTApOzwvc3Bhbj48YnI+PHNwYW4+MzIgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fTwvc3Bhbj48YnI+PHNwYW4+MzMgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxicj48c3Bhbj4zNCAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwdWJsaWMgdm9pZCBhZGp1c3RXZWlnaHRz KExpc3QmbHQ7RG91YmxlJmd0OyB3ZWlnaHRQYXJ0cywgTGlzdCZsdDtJbnRlZ2VyJmd0OyBleHBl Y3RlZFdlaWdodHNTb3J0ZWQsIGludCB0b3RhbFdlaWdodCkgezwvc3Bhbj48YnI+PHNwYW4+MzUg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7YXNzZXJ0RmFsc2Uod2VpZ2h0c1V0aWxzID09IG51bGwpOzwvc3Bhbj48 YnI+PHNwYW4+MzYgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7TWFwJmx0O1N0cmluZywgRG91YmxlJmd0OyBtYXAg PSBuZXcgSGFzaE1hcCZsdDsmZ3Q7KCk7PC9zcGFuPjxicj48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4g Jm5ic3A7Jm5ic3A7Jm5ic3A7Q0lEIDEzNjYxOTA6ICZuYnNwO1Jlc291cmNlIGxlYWtzICZuYnNw OyhSRVNPVVJDRV9MRUFLKTwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48L2Js b2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ICZuYnNwOyZuYnNwOyZuYnNwO0ZhaWxpbmcg dG8gc2F2ZSBvciBjbG9zZSByZXNvdXJjZSBjcmVhdGVkIGJ5ICJqYXZhLnV0aWwuc3RyZWFtLklu dFN0cmVhbS5yYW5nZSgwLCB3ZWlnaHRQYXJ0cy5zaXplKCkpIiBsZWFrcyBpdC48L3NwYW4+PGJy PjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxzcGFuPjM3ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO0ludFN0cmVhbS5yYW5nZSgwLCB3ZWlnaHRQYXJ0cy5zaXplKCkpLmZvckVhY2goaSAt Jmd0OyBtYXAucHV0KFN0cmluZy52YWx1ZU9mKGkpLCB3ZWlnaHRQYXJ0cy5nZXQoaSkpKTs8L3Nw YW4+PGJyPjxzcGFuPjM4ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO01hcCZsdDtTdHJpbmcsIEludGVnZXImZ3Q7 IHJlcyA9IHdlaWdodHNVdGlscy5hZGp1c3QobWFwLCB0b3RhbFdlaWdodCk7PC9zcGFuPjxicj48 c3Bhbj4zOSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthc3NlcnRFcXVhbHMoImFkanVzdGVkIHdlaWdodHMgc3Vt IHNob3VsZCBiZSBlcXVhbCB0byB0aGUgdG90YWwgd2VpZ2h0Iiw8L3NwYW4+PGJyPjxzcGFuPjQw ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO3RvdGFsV2VpZ2h0LDwvc3Bhbj48YnI+PHNwYW4+NDEgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVzLnZhbHVlcygp LnN0cmVhbSgpLm1hcFRvSW50KHggLSZndDsgeCkuc3VtKCkpOzwvc3Bhbj48YnI+PHNwYW4+NDIg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFu Pjwvc3Bhbj48YnI+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188L3NwYW4+PGJyPjxzcGFuPlRvIHZpZXcgdGhlIGRlZmVjdHMgaW4gQ292ZXJpdHkg U2NhbiB2aXNpdCwgPGEgaHJlZj0iaHR0cHM6Ly91MjM4OTMzNy5jdC5zZW5kZ3JpZC5uZXQvd2Yv Y2xpY2s/dXBuPTA4b25yWXUzNEEtMkJXY1dVbC0yRi0yQmZWMFYwNVVQeHZWaldjaC0yQmQyTUdj a2NSWTl2M1NaLTJCTHFobjY2ZnVjV3o1TkNoZFYyUU5aekxRQ1BZMWZqcVFHbEFLakZLUTRwbkRu UThkdEF3dkNFMkcwRS0zRF94RHZ5OWFUdEZWbE5nTlRGTGlDVkQwY2ljTDJLNlkzZC0yQkpJQnIt MkZwQWVNcTJHb3I1QzFaRWlRdW90M2F2Mi0yRkJuVFhJam5aZGpiMEN3LTJGaVpWNXozRFJvdG0y b3ctMkJpd2RvVnBsS2V1azduUkZyUlh6UzRqSmIzSVpYQlN4ZVpDMGJjOEtQbnVFbEhDdFFyeVVK NXUtMkZZNlFqTVVuWnVGRHUtMkJDMjFjb1J0SGZQcjF1RjlaQ3ZrVFFBVC0yQmc1ZHJIU2JOUGFz enAwWW5aenZhVUdBckdVbFhRa1B0NDhkYy0yRk5aYWl4Z0dvbXdzUFBRLTNEIj5odHRwczovL3Uy Mzg5MzM3LmN0LnNlbmRncmlkLm5ldC93Zi9jbGljaz91cG49MDhvbnJZdTM0QS0yQldjV1VsLTJG LTJCZlYwVjA1VVB4dlZqV2NoLTJCZDJNR2NrY1JZOXYzU1otMkJMcWhuNjZmdWNXejVOQ2hkVjJR Tlp6TFFDUFkxZmpxUUdsQUtqRktRNHBuRG5ROGR0QXd2Q0UyRzBFLTNEX3hEdnk5YVR0RlZsTmdO VEZMaUNWRDBjaWNMMks2WTNkLTJCSklCci0yRnBBZU1xMkdvcjVDMVpFaVF1b3QzYXYyLTJGQm5U WElqblpkamIwQ3ctMkZpWlY1ejNEUm90bTJvdy0yQml3ZG9WcGxLZXVrN25SRnJSWHpTNGpKYjNJ WlhCU3hlWkMwYmM4S1BudUVsSEN0UXJ5VUo1dS0yRlk2UWpNVW5adUZEdS0yQkMyMWNvUnRIZlBy MXVGOVpDdmtUUUFULTJCZzVkckhTYk5QYXN6cDBZblp6dmFVR0FyR1VsWFFrUHQ0OGRjLTJGTlph aXhnR29td3NQUFEtM0Q8L2E+PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPlRvIG1h bmFnZSBDb3Zlcml0eSBTY2FuIGVtYWlsIG5vdGlmaWNhdGlvbnMgZm9yICI8YSBocmVmPSJtYWls dG86bXNrcml2YW5AcmVkaGF0LmNvbSI+bXNrcml2YW5AcmVkaGF0LmNvbTwvYT4iLCBjbGljayA8 YSBocmVmPSJodHRwczovL3UyMzg5MzM3LmN0LnNlbmRncmlkLm5ldC93Zi9jbGljaz91cG49MDhv bnJZdTM0QS0yQldjV1VsLTJGLTJCZlYwVjA1VVB4dlZqV2NoLTJCZDJNR2NrY1JiVkRiaXM3MTJx WkRQLTJGQTh5MDZOcTRRWU5KZHZ6My0yQm82RDdrektHTTRCaWVHWGNGWmVWajhiYmxicFBaUzEz NXpvLTJGOXBhZ2lISGxWTXRMMXQtMkJRTmtkTU1waTJmY0FGajh5V2xZNnN4Wmh6TlVXSHZTa2VQ NkxkREhVR0RTczhQSS0zRF94RHZ5OWFUdEZWbE5nTlRGTGlDVkQwY2ljTDJLNlkzZC0yQkpJQnIt MkZwQWVNcTJHb3I1QzFaRWlRdW90M2F2Mi0yRkJuWXdtQUNKWlphLTJCa1JhMTNKVFJnbTRLNkpu b2dOb3FEWlR6TnZMUnhQNlZhbDFQMDNFRHRKM1F4VEc4dXJKLTJGQ1R1WE56RURaMjRhdTljUnFW Z3k5WVZQT2lWU3Z3N3RBWTRkenNzUmM4RVJteTFtQ3psQ2JVNi0yQjlzMDFrWWYwRVlrbzZlN1FL ajJWcFZ4VkpEOGJSTnItMkZOWGNVU3YtMkJ1MWZBNjEyaWQxTGNDTS0zRCI+aHR0cHM6Ly91MjM4 OTMzNy5jdC5zZW5kZ3JpZC5uZXQvd2YvY2xpY2s/dXBuPTA4b25yWXUzNEEtMkJXY1dVbC0yRi0y QmZWMFYwNVVQeHZWaldjaC0yQmQyTUdja2NSYlZEYmlzNzEycVpEUC0yRkE4eTA2TnE0UVlOSmR2 ejMtMkJvNkQ3a3pLR000QmllR1hjRlplVmo4YmJsYnBQWlMxMzV6by0yRjlwYWdpSEhsVk10TDF0 LTJCUU5rZE1NcGkyZmNBRmo4eVdsWTZzeFpoek5VV0h2U2tlUDZMZERIVUdEU3M4UEktM0RfeER2 eTlhVHRGVmxOZ05URkxpQ1ZEMGNpY0wySzZZM2QtMkJKSUJyLTJGcEFlTXEyR29yNUMxWkVpUXVv dDNhdjItMkZCbll3bUFDSlpaYS0yQmtSYTEzSlRSZ200SzZKbm9nTm9xRFpUek52TFJ4UDZWYWwx UDAzRUR0SjNReFRHOHVySi0yRkNUdVhOekVEWjI0YXU5Y1JxVmd5OVlWUE9pVlN2dzd0QVk0ZHpz c1JjOEVSbXkxbUN6bENiVTYtMkI5czAxa1lmMEVZa282ZTdRS2oyVnBWeFZKRDhiUk5yLTJGTlhj VVN2LTJCdTFmQTYxMmlkMUxjQ00tM0Q8L2E+PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjwv ZGl2PjwvYmxvY2txdW90ZT48L2JvZHk+PC9odG1sPg== --Apple-Mail-D6BD3946-3D96-44AC-A6CA-27DF220B7C24--

1 0

oVirt 4.0.6 RC2 build planned
by Sandro Bonazzola 21 Nov '16

21 Nov '16

Fyi oVirt developers, An oVirt build is planned for this Tuesday 10:00 AM TLV time (9:00 AM CET). Taking into consideration the time it takes for Jenkins to run a full CI everything need to be backported by Monday 11PM. Please make sure to mark as verified and CR +2 so it will be ready for merging Tuesday morning. A list of pending blockers is available here: https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.… -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 1

oVirt 4.0.6 RC2 merge / branch / tag / bugzilla reminder
by Sandro Bonazzola 21 Nov '16

21 Nov '16

All stable branch maintainers, please make sure to merge all relevant open bugs until Wednesday morning 10:00 AM TLV time (9:00 AM CET). For each package that need to be built (i.e oVirt product) please make sure every bug in MODIFIED has the right Target Release and Target Milestone. A Target release should state the version of the package you're building and should include the same version you used for the tag you just used for this build. (e.g. for ovirt-engine, tag: ovirt-engine-4.0.6, tr: 4.0.6) A list of bugs that require attention is here: https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.… -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Merge gating in Gerrit
by Barak Korren 21 Nov '16

21 Nov '16

Hi all, Perhaps the main purpose of CI, is to prevent braking code from getting merged into the stable/master branches. Unfortunately our CI is not there yet, and one of the reasons for that is that we do large amount of our CI tests only _after_ the code is merged. The reason for that is that when balancing through, but time consuming, tests (e.g. enging build with all permutations) v.s. faster but more basic ones (e.g. "findbugs" and single permutation build), we typically choose the faster tests to be run per-patch-set and leave the through testing to only be run post-merge. We'd like to change that and have the through tests also run before merge. Ideally we would like to just hook stuff to the "submit" button, but Gerrit doesn't allow one to do that easily. So instead we'll need to adopt some kind of flag to indicate we want to submit and have Jenkins "click" the submit button on our behalf if tests pass. I see two options here: 1. Use Code-Review+2 as the indicator to run "heavy" CI and merge. 2. Add an "approve" flag that maintainers can set to +1 (This is what OpenStack is doing). What would you prefer? -- Barak Korren bkorren(a)redhat.com RHEV-CI Team

7 10

system tests failing on template export
by Evgheni Dereveanchin 20 Nov '16

20 Nov '16

Hello, We've got several cases today where system tests failed when attempting to export templates: http://jenkins.ovirt.org/job/ovirt_master_system-tests/655/testReport/junit… Related engine.log looks something like this: https://paste.fedoraproject.org/449936/47643643/raw/ I could not find any obvious issues in SPM logs, could someone please take a look to confirm what may be causing this issue? Full logs from the test are available here: http://jenkins.ovirt.org/job/ovirt_master_system-tests/655/artifact/ Regards, Evgheni Dereveanchin

6 7

Failures in OST (4.0/master) ( was error msg from Jenkins )
by Eyal Edri 20 Nov '16

20 Nov '16

Renaming title and adding devel. On Sun, Nov 20, 2016 at 2:36 PM, Piotr Kliczewski <pkliczew(a)redhat.com> wrote: > The last failure seems to be storage related. > > @Nir please take a look. > > Here is engine side error: > > 2016-11-20 05:54:59,605 DEBUG [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand] > (default task-5) [59fc0074] Exception: org.ovirt.engine.core. > vdsbroker.irsbroker.IRSNoMasterDomainException: IRSGenericException: > IRSErrorException: IRSNoMasterDomainException: Cannot find master domain: > u'spUUID=1ca141f1-b64d-4a52-8861-05c7de2a72b2, msdUUID=7d4bf750-4fb8-463f- > bbb0-92156c47306e' > > and here is vdsm: > > jsonrpc.Executor/5::ERROR::2016-11-20 05:54:56,331::multipath::95:: > Storage.Multipath::(resize_devices) Could not resize device > 360014052749733c7b8248628637b990f > Traceback (most recent call last): > File "/usr/share/vdsm/storage/multipath.py", line 93, in resize_devices > _resize_if_needed(guid) > File "/usr/share/vdsm/storage/multipath.py", line 101, in > _resize_if_needed > for slave in devicemapper.getSlaves(name)] > File "/usr/share/vdsm/storage/multipath.py", line 158, in getDeviceSize > bs, phyBs = getDeviceBlockSizes(devName) > File "/usr/share/vdsm/storage/multipath.py", line 150, in > getDeviceBlockSizes > "queue", "logical_block_size")).read()) > IOError: [Errno 2] No such file or directory: > '/sys/block/sdb/queue/logical_block_size' > We now see a different error in master [1], which also indicates the hosts are in a problematic state: ( failing 'assign_hosts_network_label' test ) status: 409 reason: Conflict detail: Cannot add Label. Operation can be performed only when Host status is Maintenance, Up, NonOperational. -------------------- >> begin captured logging << -------------------- [1] http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3506/testR… > > > On Sun, Nov 20, 2016 at 12:50 PM, Eyal Edri <eedri(a)redhat.com> wrote: > >> >> >> On Sun, Nov 20, 2016 at 1:42 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote: >> >>> >>> >>> On Sun, Nov 20, 2016 at 1:30 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote: >>> >>>> >>>> >>>> On Sun, Nov 20, 2016 at 1:18 PM, Eyal Edri <eedri(a)redhat.com> wrote: >>>> >>>>> the test fails to run VM because no hosts are in UP state(?) [1], not >>>>> sure it is related to the triggering patch[2] >>>>> >>>>> status: 400 >>>>> reason: Bad Request >>>>> detail: There are no hosts to use. Check that the cluster contains at >>>>> least one host in Up state. >>>>> >>>>> Thoughts? Shouldn't we fail the test earlier we hosts are not UP? >>>>> >>>> >>>> Yes. It's more likely that we are picking the wrong host or so, but who >>>> knows - where are the engine and VDSM logs? >>>> >>> >>> A simple grep on the engine.log[1] finds serveral unrelated issues I'm >>> not sure are reported, it's despairing to even begin... >>> That being said, I don't see the issue there. We may need better logging >>> on the API level, to see what is being sent. Is it consistent? >>> >> >> Just failed now the first time, I didn't see it before. >> >> >>> Y. >>> >>> >>> [1] http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_4. >>> 0/3015/artifact/exported-artifacts/basic_suite_4.0.sh-el7/ex >>> ported-artifacts/test_logs/basic-suite-4.0/post-004_basic_ >>> sanity.py/lago-basic-suite-4-0-engine/_var_log_ovirt-engine/engine.log >>> >>>> Y. >>>> >>>> >>>>> >>>>> >>>>> [1] http://jenkins.ovirt.org/job/test-repo_ovirt_experimenta >>>>> l_4.0/3015/testReport/junit/(root)/004_basic_sanity/vm_run/ >>>>> [2] http://jenkins.ovirt.org/job/ovirt-engine_4.0_build-arti >>>>> facts-el7-x86_64/1535/changes#detail >>>>> >>>>> >>>>> >>>>> On Sun, Nov 20, 2016 at 1:00 PM, <jenkins(a)jenkins.phx.ovirt.org> >>>>> wrote: >>>>> >>>>>> Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_4. >>>>>> 0/3015/, >>>>>> Build Number: 3015, >>>>>> Build Status: FAILURE >>>>>> _______________________________________________ >>>>>> Infra mailing list >>>>>> Infra(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/infra >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Eyal Edri >>>>> Associate Manager >>>>> RHV DevOps >>>>> EMEA ENG Virtualization R&D >>>>> Red Hat Israel >>>>> >>>>> phone: +972-9-7692018 >>>>> irc: eedri (on #tlv #rhev-dev #rhev-integ) >>>>> >>>> >>>> >>> >> >> >> -- >> Eyal Edri >> Associate Manager >> RHV DevOps >> EMEA ENG Virtualization R&D >> Red Hat Israel >> >> phone: +972-9-7692018 >> irc: eedri (on #tlv #rhev-dev #rhev-integ) >> > > -- Eyal Edri Associate Manager RHV DevOps EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

3 2

Re: [ovirt-devel] Where's MOM (on latest master)
by Michal Skrivanek 18 Nov '16

18 Nov '16

> On 18 Nov 2016, at 12:35, Martin Sivak <msivak(a)redhat.com> wrote: > >> I don't think it is related to version X or Y. It is a race, so might be >> related to other factors. > > It never (seriously: NEVER) happened with xml-rpc before 4.0.5. that is surprising but we also didn’t have lago before;-) > >> likely because json-rpc is initialized after xml-rpc….or indeed whatever >> else;-) > > But this is not about jsonrpc. The socket itself is shared according > to what Piotr said. it is > >> btw you likely still want to have a retry in mom once it >> starts responding due to delayed vdsm async recovery taking potentially >> minutes > > We handle this already. The only issue is the connection refused state. then why don’t you handle the connection state as well? isn’t that a simple fix? > > > Martin > > > On Fri, Nov 18, 2016 at 12:19 PM, Michal Skrivanek > <michal.skrivanek(a)redhat.com> wrote: >> >> On 18 Nov 2016, at 12:12, Oved Ourfali <oourfali(a)redhat.com> wrote: >> >> I don't think it is related to version X or Y. It is a race, so might be >> related to other factors. >> >> >> likely because json-rpc is initialized after xml-rpc….or indeed whatever >> else;-) >> >> either way it needs to be solved. Either by improving the systemd service >> file or mom retry (btw you likely still want to have a retry in mom once it >> starts responding due to delayed vdsm async recovery taking potentially >> minutes) >> >> >> On Nov 18, 2016 12:59 PM, "Martin Sivak" <msivak(a)redhat.com> wrote: >>> >>>> Are we / can we use systemd socket activation there? >>> >>> That actually requires systemd specific code iirc (to take over the >>> standing by socket). I am actually wondering why the xml-rpc in 4.0.4 >>> was fine and json-rpc in 4.0.6 is too slow. >>> >>> Martin >>> >>> On Fri, Nov 18, 2016 at 11:53 AM, Anton Marchukov <amarchuk(a)redhat.com> >>> wrote: >>>> Hello All. >>>> >>>> Are we / can we use systemd socket activation there? >>>> >>>> Anton. >>>> >>>> On Fri, Nov 18, 2016 at 11:21 AM, Martin Sivak <msivak(a)redhat.com> >>>> wrote: >>>>> >>>>> What about making vdsm ready to answer connections when it returns to >>>>> systemd instead? I hate workarounds and this always worked fine. >>>>> >>>>> Martin >>>>> >>>>> On Fri, Nov 18, 2016 at 11:13 AM, Oved Ourfali <oourfali(a)redhat.com> >>>>> wrote: >>>>>> Seems like a race regardless of the protocol. >>>>>> Should you add a retry? >>>>>> >>>>>> >>>>>> On Nov 18, 2016 11:52 AM, "Martin Sivak" <msivak(a)redhat.com> wrote: >>>>>>> >>>>>>> Yes, because VDSM is supposed to be up (there is systemd >>>>>>> dependency). >>>>>>> This always worked fine with xml-rpc. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> On Fri, Nov 18, 2016 at 10:14 AM, Nir Soffer <nsoffer(a)redhat.com> >>>>>>> wrote: >>>>>>>> On Fri, Nov 18, 2016 at 10:45 AM, Martin Sivak <msivak(a)redhat.com> >>>>>>>> wrote: >>>>>>>>> This happens because MOM can't connect to VDSM and so it quits. >>>>>>>> >>>>>>>> So mom try once to connect and if the connection fails it quits? >>>>>>>> >>>>>>>>> We >>>>>>>>> discussed it on the mailinglist >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> https://lists.fedoraproject.org/archives/list/vdsm-devel@lists.fedorahosted… >>>>>>>>> http://lists.ovirt.org/pipermail/devel/2016-November/014101.html >>>>>>>>> >>>>>>>>> This issue never happened with XML-RPC. >>>>>>>>> >>>>>>>>> Shira reported it as >>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1393012 >>>>>>>>> >>>>>>>>> Martin >>>>>>>>> >>>>>>>>> On Thu, Nov 17, 2016 at 7:42 PM, Yaniv Kaul <ykaul(a)redhat.com> >>>>>>>>> wrote: >>>>>>>>>> I've recently seen, including now on Master, the following >>>>>>>>>> warnings: >>>>>>>>>> Nov 17 13:33:25 lago-basic-suite-master-host0 systemd[1]: >>>>>>>>>> Started >>>>>>>>>> MOM >>>>>>>>>> instance configured for VDSM purposes. >>>>>>>>>> Nov 17 13:33:25 lago-basic-suite-master-host0 systemd[1]: >>>>>>>>>> Starting >>>>>>>>>> MOM >>>>>>>>>> instance configured for VDSM purposes... >>>>>>>>>> Nov 17 13:33:35 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, Policy could not be set. >>>>>>>>>> Nov 17 13:33:39 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> Nov 17 13:33:39 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, KSM stats will be missing. >>>>>>>>>> Nov 17 13:33:55 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> Nov 17 13:33:55 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, KSM stats will be missing. >>>>>>>>>> Nov 17 13:34:10 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> Nov 17 13:34:10 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, KSM stats will be missing. >>>>>>>>>> Nov 17 13:34:26 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> Nov 17 13:34:26 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, KSM stats will be missing. >>>>>>>>>> Nov 17 13:34:42 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> Nov 17 13:34:42 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, KSM stats will be missing. >>>>>>>>>> Nov 17 13:34:57 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> Nov 17 13:34:57 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, KSM stats will be missing. >>>>>>>>>> Nov 17 13:35:12 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Any ideas what this is and why? >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Devel mailing list >>>>>>>>>> Devel(a)ovirt.org >>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>>>>> _______________________________________________ >>>>>>>>> Devel mailing list >>>>>>>>> Devel(a)ovirt.org >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>>> _______________________________________________ >>>>>>> Devel mailing list >>>>>>> Devel(a)ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>>> >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Devel mailing list >>>>> Devel(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>> >>>> >>>> >>>> >>>> -- >>>> Anton Marchukov >>>> Senior Software Engineer - RHEV CI - Red Hat >>>> >> >> _______________________________________________ >> Devel mailing list >> Devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> >>

2 1

Where's MOM (on latest master)
by Yaniv Kaul 18 Nov '16

18 Nov '16

I've recently seen, including now on Master, the following warnings: Nov 17 13:33:25 lago-basic-suite-master-host0 systemd[1]: Started MOM instance configured for VDSM purposes. Nov 17 13:33:25 lago-basic-suite-master-host0 systemd[1]: Starting MOM instance configured for VDSM purposes... Nov 17 13:33:35 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, Policy could not be set. Nov 17 13:33:39 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Nov 17 13:33:39 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, KSM stats will be missing. Nov 17 13:33:55 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Nov 17 13:33:55 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, KSM stats will be missing. Nov 17 13:34:10 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Nov 17 13:34:10 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, KSM stats will be missing. Nov 17 13:34:26 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Nov 17 13:34:26 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, KSM stats will be missing. Nov 17 13:34:42 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Nov 17 13:34:42 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, KSM stats will be missing. Nov 17 13:34:57 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Nov 17 13:34:57 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, KSM stats will be missing. Nov 17 13:35:12 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Any ideas what this is and why?

7 15

Introduce new package decencies in vdsm
by Yaniv Bronheim 17 Nov '16

17 Nov '16

Hi After merging https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:c… we need now for any new requirement to add a line in: check-patch.packages.el7 check-patch.packages.fc24 check-merged.packages.el7 check-merged.packages.fc24 vdsm.spec.in Dockerfile.centos Dockerfile.fedora seems like we can add it once to the spec with section for fedora and centos and the rest of the places will use yum-builddep. sounds more reasonable to me and probably the right way to work with rpms dependencies. no? *Yaniv Bronhaim.*

4 4

oVirt Neutron External Provider
by Than Maung 17 Nov '16

17 Nov '16

All, Is there a guide for getting oVirt 4.0.4 going with networks created in Neutron? We are having problems with VMs not getting DHCP at all but they are showing up in the OpenStack Dashboard interface under Ports with the correct MAC IDs and the IP that the DHCP agent had assigned them. I'm using OpenStack Newton version and the controller is working all properly. We are trying to follow these two guides in trying to get virtual networks to work but experiencing problems. http://docs.openstack.org/newton/install-guide-rdo/neutron.html http://captainkvm.com/2016/09/integrating-rhv-openstack-neutron/ Sincerely, -- Than H. Maung, CISSP tmaung(a)techintsolutions.com (571) 295-8462

3 2