December 2017 - Devel - oVirt List Archives

Mailing-Lists upgrade
by Marc Dequènes (Duck) 28 Apr '18

28 Apr '18

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IfGqXrbgT9wNNdIsvS8kI8WdhEQHlgkiq Content-Type: multipart/mixed; boundary="AUFHCWPQQknM84fF2kF4uGjIv4blC9bMv"; protected-headers="v1" From: =?UTF-8?B?TWFyYyBEZXF1w6huZXMgKER1Y2sp?= <duck(a)redhat.com> To: oVirt Infra <infra(a)ovirt.org>, users <users(a)ovirt.org>, devel <devel(a)ovirt.org> Message-ID: <c5c71fce-0290-e97a-ddd0-eab0e6fccea4(a)redhat.com> Subject: Mailing-Lists upgrade --AUFHCWPQQknM84fF2kF4uGjIv4blC9bMv Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Quack, On behalf of the oVirt infra team, I'd like to announce the current Mailing-Lists system is going to be upgraded to a brand new Mailman 3 installation on Monday during the slot 11:00-12:00 JST. It should not take a full hour to migrate as we already made incremental synchronization with the current system but better keep some margin. The system will then take over delivery of the mails but might be a bit slow at first as it needs to reindex all the archived mails (which might take a few hours). To manage your subscriptions and delivery settings you can do this easily on the much nicer web interface (https://lists.ovirt.org) There is a notion of account so you don't need to login separately for each ML.= You can Sign In using Fedora, GitHub or Google or create a local account if you prefer. Please keep in mind signing in with a different method would create separate accounts (which cannot be merged at the moment). But you can easily link your account to other authentication methods in your settings (click on you name in the up-right corner -> Account -> Account Connections). As for the original mail archives, because the previous system did not have stable URLs, we cannot create mappings to the new pages. We decided to keep the old archives around on the same URL (/pipermail), so the Internet links would still work fine. Hope you'd be happy with the new system. \_o< --AUFHCWPQQknM84fF2kF4uGjIv4blC9bMv-- --IfGqXrbgT9wNNdIsvS8kI8WdhEQHlgkiq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEcpcqg+UmRT3yiF+BVen596wcRD8FAlmwx0MACgkQVen596wc RD9LTQ/+LtUncsq9K8D/LX8wqUTd6VyPwAD5UnAk5c3H/2tmyVA0u7FIfhEyPsXs Z//LE9FEneTDqDVRi1Dw9I54K0ZwxPBemi71dXfwgBI7Ay0ezkbLWrA168Mt9spE tHAODEuxPt2to2aqaS4ujogrkp/gvEP8ILoxPEqoTPCJ/eDTPAu/I1a2JzjMPK3n 2BBS6D8z0TLAf7w1n72TsgX2QzJW57ig/0HELyjvat2/K8V3HSrkwiKlsdULQDWe zB+aMde7r6UoyVKHqlu4asTl2tU/lGZ+e31Hd9Bnx1/oZOJdzslGOhEo9Qoz6763 AHWU9LKiK4NtxYHj2UQTWhndr8PiTtTmR73eIDmkb0cuRXxzjl9VQbwYJ0Kbrmfp attTqpc2CnEojTNXUUNSmNxotZoYXZiX8ZvjPfSgRVr15TUYujzlOfG+lUynbQMV 9rQ9/m58wgwYUymMpOIsRGaIcAKzjm+WpuuVnO+bS2AfmcBkGMQRoIhfV+3SkS8q kT9cDXgcDZOzVFcnZZB4EjbycMcPgZDcoHxU88VdYH+jFJYvvb21esgswVF/wJ2Z uEI/chp4+ADaQhl8ehZNWMSZq125v6SeirPhBNgLG7zFVZI1S9Tm/6qFmH+ajQY7 nCk1X9HZlB1ubex1X+HibRz9QKOilkMgkADyJ4yMDckwYj93sx0= =l6uN -----END PGP SIGNATURE----- --IfGqXrbgT9wNNdIsvS8kI8WdhEQHlgkiq--

2 4

[IMPORTANT] getting rid of our implementation of UUID generation in 4.2.1
by Eli Mesika 16 Jan '18

16 Jan '18

Hi We had decided to drop our UUID generation function from DB in 4.2.1 and use the one provided by PG (using an extension) Please note that once this patch [1] is merged , you will have to do the following steps in your env in order that it will continue working. 1) make sure that the postgresql-contrib is installed on your machine (yum/dnf install postgresql-contrib -y) 2) run the following command from psql prompt while logging in with a DB admin (postgres) user a) DROP FUNCTION IF EXISTS uuid_generate_v1(); b) CREATE EXTENSION "uuid-ossp";' 3) validate from psql prompt by : # select * from pg_available_extensions where name = 'uuid-ossp' and installed_version IS NOT NULL; You should get the following result -[ RECORD 1 ]-----+------------------------------------------------ name | uuid-ossp default_version | 1.0 installed_version | 1.0 comment | generate universally unique identifiers (UUIDs) Please contact me for any questions or problems you encounter after this patch is merged to master. [1] https://gerrit.ovirt.org/#/c/84832/ Thanks Eli Mesika

6 6

sslStompReactor just created once, may cause engine failed to connect to new node
by pengyixiang 03 Jan '18

03 Jan '18

------=_Part_31563_326541847.1514165212297 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 aGVsbG8sIGV2ZXJ5b25lIQogICAgIEkgdXNlIFNjZW5hcmlvQ2xpZW50IHRvIGNhbGwgdmRzbS1q c29ucnBjLWNsaWVudCwgYnV0IEkgZmluZCBhZnRlciBteSBlbmdpbmUgY29ubmVjdGVkIHRvIG9u ZSBub2RlLCBJIG5ldyBhIG5vZGUsIHRoZW4gdGhlIGNlcnRzKGVuZ2luZS5wMTIpIGlzIGNoYW5n ZWQsCgpidXQgZW5naW5lIGNhbiBub3QgY29ubmVjdGVkIHRvIG5ldyBub2RlLCBhdCBsYXN0LCBJ IGZpbmQgdGhlIHByb2JsZW0gaW4gdGhlcmUgWzFdLCAgYW5kIEkgdGhpbmsgcnBjJ3MgY2VydHMg dG8gbm9kZSB0aGF0IGlzIHN0aWxsIG9sZCwgc28gSSB0cnkgdG8gY2hhbmdlZCBjb2RlIHRvIFsy XSwKdGhlbiByZXBlYXQgdGhlIHRlc3Qgd2F5LCBpdCB3b3JrcyB3ZWxsLCB0aGUgb3ZpcnQncyBl bmdpbmUgZG9lc24ndCBtZWV0IHRoZSB0cm91YmxlIGFuZCBob3cgZGlkIHlvdSBkbz8gY2xpZW50 IGlzIGNyZWF0ZWQgbGlrZSB0aGlzIFszXS4KCgoKCgoKCgoKWzFdICAgaHR0cHM6Ly9naXRodWIu Y29tL29WaXJ0L3Zkc20tanNvbnJwYy1qYXZhL2Jsb2IvMDc4MjMzZTYwYzI0ZjhiODUyNWIzYmY1 ZmIxYzVhYjlmMWM0ZTBmNC9jbGllbnQvc3JjL21haW4vamF2YS9vcmcvb3ZpcnQvdmRzbS9qc29u cnBjL2NsaWVudC9yZWFjdG9ycy9SZWFjdG9yRmFjdG9yeS5qYXZhI0w3NgoKCgpbMl0gIAoKcHJp dmF0ZSBzdGF0aWMgUmVhY3RvciBnZXRTc2xTdG9tcFJlYWN0b3IoTWFuYWdlclByb3ZpZGVyIHBy b3ZpZGVyKSB0aHJvd3MgQ2xpZW50Q29ubmVjdGlvbkV4Y2VwdGlvbiB7Ci8vICAgICAgICBpZiAo c3NsU3RvbXBSZWFjdG9yICE9IG51bGwpIHsKLy8gICAgICAgICAgICByZXR1cm4gc3NsU3RvbXBS ZWFjdG9yOwovLyAgICAgICAgfQpzeW5jaHJvbml6ZWQgKFJlYWN0b3JGYWN0b3J5LmNsYXNzKSB7 Ci8vICAgICAgICAgICAgaWYgKHNzbFN0b21wUmVhY3RvciAhPSBudWxsKSB7Ci8vICAgICAgICAg ICAgICAgIHJldHVybiBzc2xTdG9tcFJlYWN0b3I7Ci8vICAgICAgICAgICAgfQp0cnkgewpzc2xT dG9tcFJlYWN0b3IgPSBuZXcgU1NMU3RvbXBSZWFjdG9yKHByb3ZpZGVyLmdldFNTTENvbnRleHQo KSk7CiAgICAgICAgICAgIH0gY2F0Y2ggKElPRXhjZXB0aW9uIHwgR2VuZXJhbFNlY3VyaXR5RXhj ZXB0aW9uIGUpIHsKdGhyb3cgbmV3IENsaWVudENvbm5lY3Rpb25FeGNlcHRpb24oZSk7CiAgICAg ICAgICAgIH0KICAgICAgICB9CnJldHVybiBzc2xTdG9tcFJlYWN0b3I7CiAgICB9CgpbM10gCnB1 YmxpYyBTY2VuYXJpb0NsaWVudChTdHJpbmcgaG9zdG5hbWUsIGludCBwb3J0KSB0aHJvd3MgQ2xp ZW50Q29ubmVjdGlvbkV4Y2VwdGlvbiB7CnRoaXMucmVhY3RvciA9IFJlYWN0b3JGYWN0b3J5Lmdl dFJlYWN0b3IoUHJvdmlkZXJGYWN0b3J5LmdldFByb3ZpZGVyKCksIFJlYWN0b3JUeXBlLlNUT01Q KTsKZmluYWwgUmVhY3RvckNsaWVudCBjbGllbnQgPSB0aGlzLnJlYWN0b3IuY3JlYXRlQ2xpZW50 KGhvc3RuYW1lLCBwb3J0KTsKICAgIGNsaWVudC5zZXRDbGllbnRQb2xpY3kobmV3IERlZmF1bHRT dG9tcENvbm5lY3Rpb25Qb2xpY3koKSk7CnRoaXMud29ya2VyID0gUmVhY3RvckZhY3RvcnkuZ2V0 V29ya2VyKFBBUkFMTEVMSVNNKTsKdGhpcy5qc29uQ2xpZW50ID0gdGhpcy53b3JrZXIucmVnaXN0 ZXIoY2xpZW50KTsKdGhpcy5qc29uQ2xpZW50LnNldFJldHJ5UG9saWN5KG5ldyBEZWZhdWx0U3Rv bXBDbGllbnRQb2xpY3koKSk7Cn0= ------=_Part_31563_326541847.1514165212297 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+aGVsbG8sIGV2ZXJ5b25lITwvZGl2PjxkaXY+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgdXNlIFNjZW5hcmlvQ2xpZW50IHRvIGNhbGwgdmRzbS1qc29u cnBjLWNsaWVudCwgYnV0IEkgZmluZCBhZnRlciBteSBlbmdpbmUgY29ubmVjdGVkIHRvIG9uZSBu b2RlLCBJIG5ldyBhIG5vZGUsIHRoZW4gdGhlIGNlcnRzKGVuZ2luZS5wMTIpIGlzIGNoYW5nZWQs IDxicj48L2Rpdj48ZGl2PmJ1dCBlbmdpbmUgY2FuIG5vdCBjb25uZWN0ZWQgdG8gbmV3IG5vZGUs IGF0IGxhc3QsIEkgZmluZCB0aGUgcHJvYmxlbSBpbiB0aGVyZSBbMV0sJm5ic3A7IGFuZCBJIHRo aW5rIHJwYydzIGNlcnRzIHRvIG5vZGUgdGhhdCBpcyBzdGlsbCBvbGQsIHNvIEkgdHJ5IHRvIGNo YW5nZWQgY29kZSB0byBbMl0sPC9kaXY+PGRpdj4gdGhlbiByZXBlYXQgdGhlIHRlc3Qgd2F5LCBp dCB3b3JrcyB3ZWxsLCB0aGUgb3ZpcnQncyBlbmdpbmUgZG9lc24ndCBtZWV0IHRoZSB0cm91Ymxl IGFuZCBob3cgZGlkIHlvdSBkbz8gY2xpZW50IGlzIGNyZWF0ZWQgbGlrZSB0aGlzIFszXS48YnI+ PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj5bMV0mbmJzcDsmbmJzcDsgaHR0cHM6Ly9naXRodWIuY29tL29WaXJ0L3Zk c20tanNvbnJwYy1qYXZhL2Jsb2IvMDc4MjMzZTYwYzI0ZjhiODUyNWIzYmY1ZmIxYzVhYjlmMWM0 ZTBmNC9jbGllbnQvc3JjL21haW4vamF2YS9vcmcvb3ZpcnQvdmRzbS9qc29ucnBjL2NsaWVudC9y ZWFjdG9ycy9SZWFjdG9yRmFjdG9yeS5qYXZhI0w3Njxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2PlsyXSZuYnNwOyZuYnNwOyA8YnI+PC9kaXY+PGRpdj48cHJlIHN0eWxlPSJiYWNrZ3JvdW5k LWNvbG9yOiNmZmZmZmY7Y29sb3I6IzAwMDAwMDtmb250LWZhbWlseTonRGVqYVZ1IFNhbnMgTW9u byc7Zm9udC1zaXplOjExLjNwdDsiPiAgICA8c3BhbiBzdHlsZT0iY29sb3I6IzAwMDA4MDtmb250 LXdlaWdodDpib2xkOyI+cHJpdmF0ZSBzdGF0aWMgPC9zcGFuPlJlYWN0b3IgZ2V0U3NsU3RvbXBS ZWFjdG9yKE1hbmFnZXJQcm92aWRlciBwcm92aWRlcikgPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAw ODA7Zm9udC13ZWlnaHQ6Ym9sZDsiPnRocm93cyA8L3NwYW4+Q2xpZW50Q29ubmVjdGlvbkV4Y2Vw dGlvbiB7PGJyPjxzcGFuIHN0eWxlPSJjb2xvcjojODA4MDgwO2ZvbnQtc3R5bGU6aXRhbGljOyI+ Ly8gICAgICAgIGlmIChzc2xTdG9tcFJlYWN0b3IgIT0gbnVsbCkgezxicj48L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOiM4MDgwODA7Zm9udC1zdHlsZTppdGFsaWM7Ij4vLyAgICAgICAgICAgIHJl dHVybiBzc2xTdG9tcFJlYWN0b3I7PGJyPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzgwODA4 MDtmb250LXN0eWxlOml0YWxpYzsiPi8vICAgICAgICB9PGJyPjwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6IzgwODA4MDtmb250LXN0eWxlOml0YWxpYzsiPiAgICAgICAgPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAwMDgwO2ZvbnQtd2VpZ2h0OmJvbGQ7Ij5zeW5jaHJvbml6ZWQgPC9zcGFu PihSZWFjdG9yRmFjdG9yeS48c3BhbiBzdHlsZT0iY29sb3I6IzAwMDA4MDtmb250LXdlaWdodDpi b2xkOyI+Y2xhc3M8L3NwYW4+KSB7PGJyPjxzcGFuIHN0eWxlPSJjb2xvcjojODA4MDgwO2ZvbnQt c3R5bGU6aXRhbGljOyI+Ly8gICAgICAgICAgICBpZiAoc3NsU3RvbXBSZWFjdG9yICE9IG51bGwp IHs8YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODA4MDgwO2ZvbnQtc3R5bGU6aXRhbGlj OyI+Ly8gICAgICAgICAgICAgICAgcmV0dXJuIHNzbFN0b21wUmVhY3Rvcjs8YnI+PC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjojODA4MDgwO2ZvbnQtc3R5bGU6aXRhbGljOyI+Ly8gICAgICAgICAg ICB9PGJyPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzgwODA4MDtmb250LXN0eWxlOml0YWxp YzsiPiAgICAgICAgICAgIDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMDA4MDtmb250LXdl aWdodDpib2xkOyI+dHJ5IDwvc3Bhbj57PGJyPiAgICAgICAgICAgICAgICA8c3BhbiBzdHlsZT0i Y29sb3I6IzY2MGU3YTtmb250LXN0eWxlOml0YWxpYzsiPnNzbFN0b21wUmVhY3RvciA8L3NwYW4+ PSA8c3BhbiBzdHlsZT0iY29sb3I6IzAwMDA4MDtmb250LXdlaWdodDpib2xkOyI+bmV3IDwvc3Bh bj5TU0xTdG9tcFJlYWN0b3IocHJvdmlkZXIuZ2V0U1NMQ29udGV4dCgpKTs8YnI+ICAgICAgICAg ICAgfSA8c3BhbiBzdHlsZT0iY29sb3I6IzAwMDA4MDtmb250LXdlaWdodDpib2xkOyI+Y2F0Y2gg PC9zcGFuPihJT0V4Y2VwdGlvbiB8IEdlbmVyYWxTZWN1cml0eUV4Y2VwdGlvbiBlKSB7PGJyPiAg ICAgICAgICAgICAgICA8c3BhbiBzdHlsZT0iY29sb3I6IzAwMDA4MDtmb250LXdlaWdodDpib2xk OyI+dGhyb3cgbmV3IDwvc3Bhbj5DbGllbnRDb25uZWN0aW9uRXhjZXB0aW9uKGUpOzxicj4gICAg ICAgICAgICB9PGJyPiAgICAgICAgfTxicj4gICAgICAgIDxzcGFuIHN0eWxlPSJjb2xvcjojMDAw MDgwO2ZvbnQtd2VpZ2h0OmJvbGQ7Ij5yZXR1cm4gPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjoj NjYwZTdhO2ZvbnQtc3R5bGU6aXRhbGljOyI+c3NsU3RvbXBSZWFjdG9yPC9zcGFuPjs8YnI+ICAg IH08YnI+PGJyPlszXSA8YnI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwODA7Zm9udC13ZWlnaHQ6 Ym9sZDsiPnB1YmxpYyA8L3NwYW4+U2NlbmFyaW9DbGllbnQoU3RyaW5nIGhvc3RuYW1lLCA8c3Bh biBzdHlsZT0iY29sb3I6IzAwMDA4MDtmb250LXdlaWdodDpib2xkOyI+aW50IDwvc3Bhbj5wb3J0 KSA8c3BhbiBzdHlsZT0iY29sb3I6IzAwMDA4MDtmb250LXdlaWdodDpib2xkOyI+dGhyb3dzIDwv c3Bhbj5DbGllbnRDb25uZWN0aW9uRXhjZXB0aW9uIHs8YnI+ICAgIDxzcGFuIHN0eWxlPSJjb2xv cjojMDAwMDgwO2ZvbnQtd2VpZ2h0OmJvbGQ7Ij50aGlzPC9zcGFuPi48c3BhbiBzdHlsZT0iY29s b3I6IzY2MGU3YTtmb250LXdlaWdodDpib2xkOyI+cmVhY3RvciA8L3NwYW4+PSBSZWFjdG9yRmFj dG9yeS48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTppdGFsaWM7Ij5nZXRSZWFjdG9yPC9zcGFuPihQ cm92aWRlckZhY3RvcnkuPHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6aXRhbGljOyI+Z2V0UHJvdmlk ZXI8L3NwYW4+KCksIFJlYWN0b3JUeXBlLjxzcGFuIHN0eWxlPSJjb2xvcjojNjYwZTdhO2ZvbnQt d2VpZ2h0OmJvbGQ7Zm9udC1zdHlsZTppdGFsaWM7Ij5TVE9NUDwvc3Bhbj4pOzxicj4gICAgPHNw YW4gc3R5bGU9ImNvbG9yOiMwMDAwODA7Zm9udC13ZWlnaHQ6Ym9sZDsiPmZpbmFsIDwvc3Bhbj5S ZWFjdG9yQ2xpZW50IGNsaWVudCA9IDxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMDgwO2ZvbnQtd2Vp Z2h0OmJvbGQ7Ij50aGlzPC9zcGFuPi48c3BhbiBzdHlsZT0iY29sb3I6IzY2MGU3YTtmb250LXdl aWdodDpib2xkOyI+cmVhY3Rvcjwvc3Bhbj4uY3JlYXRlQ2xpZW50KGhvc3RuYW1lLCBwb3J0KTs8 YnI+ICAgIGNsaWVudC5zZXRDbGllbnRQb2xpY3koPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwODA7 Zm9udC13ZWlnaHQ6Ym9sZDsiPm5ldyA8L3NwYW4+RGVmYXVsdFN0b21wQ29ubmVjdGlvblBvbGlj eSgpKTs8YnI+ICAgIDxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMDgwO2ZvbnQtd2VpZ2h0OmJvbGQ7 Ij50aGlzPC9zcGFuPi48c3BhbiBzdHlsZT0iY29sb3I6IzY2MGU3YTtmb250LXdlaWdodDpib2xk OyI+d29ya2VyIDwvc3Bhbj49IFJlYWN0b3JGYWN0b3J5LjxzcGFuIHN0eWxlPSJmb250LXN0eWxl Oml0YWxpYzsiPmdldFdvcmtlcjwvc3Bhbj4oPHNwYW4gc3R5bGU9ImNvbG9yOiM2NjBlN2E7Zm9u dC13ZWlnaHQ6Ym9sZDtmb250LXN0eWxlOml0YWxpYzsiPlBBUkFMTEVMSVNNPC9zcGFuPik7PGJy PiAgICA8c3BhbiBzdHlsZT0iY29sb3I6IzAwMDA4MDtmb250LXdlaWdodDpib2xkOyI+dGhpczwv c3Bhbj4uPHNwYW4gc3R5bGU9ImNvbG9yOiM2NjBlN2E7Zm9udC13ZWlnaHQ6Ym9sZDsiPmpzb25D bGllbnQgPC9zcGFuPj0gPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwODA7Zm9udC13ZWlnaHQ6Ym9s ZDsiPnRoaXM8L3NwYW4+LjxzcGFuIHN0eWxlPSJjb2xvcjojNjYwZTdhO2ZvbnQtd2VpZ2h0OmJv bGQ7Ij53b3JrZXI8L3NwYW4+LnJlZ2lzdGVyKGNsaWVudCk7PGJyPiAgICA8c3BhbiBzdHlsZT0i Y29sb3I6IzAwMDA4MDtmb250LXdlaWdodDpib2xkOyI+dGhpczwvc3Bhbj4uPHNwYW4gc3R5bGU9 ImNvbG9yOiM2NjBlN2E7Zm9udC13ZWlnaHQ6Ym9sZDsiPmpzb25DbGllbnQ8L3NwYW4+LnNldFJl dHJ5UG9saWN5KDxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMDgwO2ZvbnQtd2VpZ2h0OmJvbGQ7Ij5u ZXcgPC9zcGFuPkRlZmF1bHRTdG9tcENsaWVudFBvbGljeSgpKTs8YnI+fTwvcHJlPjwvZGl2Pjwv ZGl2Pjxicj48YnI+PHNwYW4gdGl0bGU9Im5ldGVhc2Vmb290ZXIiPjxwPiZuYnNwOzwvcD48L3Nw YW4+ ------=_Part_31563_326541847.1514165212297--

3 4

oVirt s390x support - some questions for maintainers
by Barak Korren 03 Jan '18

03 Jan '18

Hi to all project maintainers, As you may know, over the last few months the oVirt project had got some code contributions geared towards enabling the use of s390x (Mainframe) machines as hypervisor hosts. As you may also know, if you've followed the relevant thread, some work had been done in collaboration with the Fedora community to enable os390x support in oVirt`s CI system. We're now at the point where we can take the final step and enable automated builds of node components for s390x/fc27. Looking at what we curently build for ppc64le, I already took the time and submitted patches to enable build jobs for vdsm [2], ovirt-host [3], and ioprocess [4]. The relevant maintainers should have had these patches land in thair inbpx already. Few questions remain however: 1. When would be the best time to merge the patches mentioned above? Given that some of the projects do not support fc27 yet, that the new build jobs may raise issues and that the 4.2 release is fast approaching, the right timing should be considered carefully. 2. Which additional projects need to be build? I can see we build some SDK components for ppc64le as wel, are those dependences of vdsm? Will we need to build then for s390x? [1]: http://jenkins.ovirt.org/search/?q=master_build-artifacts-el7-ppc64le [2]: https://gerrit.ovirt.org/c/85487 [3]: https://gerrit.ovirt.org/c/85486 [4]: https://gerrit.ovirt.org/c/85485 -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted

4 8

[ OST Failure Report ] [ oVirt master ] [ 24/12/2017 ] [use_ovn_provider]
by Barak Korren 29 Dec '17

29 Dec '17

Test failed: [ 098_ovirt_provider_ovn.use_ovn_provider ] Link to suspected patches: - Linked test failed on: https://gerrit.ovirt.org/#/c/85703/3 - It seems OVN patches had been failing tests ever since: https://gerrit.ovirt.org/#/c/85645/2 Link to Job: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4492/ Link to all logs: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4492/artifact… Error snippet from log: <error> Fault reason is "Operation Failed". Fault detail is "Failed to communicate with the external provider, see log for additional details.". HTTP response code is 400. -------------------- >> begin captured logging << -------------------- requests.packages.urllib3.connectionpool: INFO: * Starting new HTTPS connection (1): 192.168.201.4 py.warnings: WARNING: * Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html requests.packages.urllib3.connectionpool: DEBUG: "POST /v2.0/tokens/ HTTP/1.1" 200 None requests.packages.urllib3.connectionpool: INFO: * Starting new HTTPS connection (1): 192.168.201.4 requests.packages.urllib3.connectionpool: DEBUG: "GET /v2.0/networks/ HTTP/1.1" 200 None requests.packages.urllib3.connectionpool: INFO: * Starting new HTTPS connection (1): 192.168.201.4 requests.packages.urllib3.connectionpool: DEBUG: "GET /v2.0/ports/ HTTP/1.1" 200 None requests.packages.urllib3.connectionpool: INFO: * Starting new HTTPS connection (1): 192.168.201.4 requests.packages.urllib3.connectionpool: DEBUG: "GET /v2.0/subnets/ HTTP/1.1" 200 None requests.packages.urllib3.connectionpool: INFO: * Starting new HTTPS connection (1): 192.168.201.4 requests.packages.urllib3.connectionpool: DEBUG: "POST /v2.0/networks/ HTTP/1.1" 201 None requests.packages.urllib3.connectionpool: INFO: * Starting new HTTPS connection (1): 192.168.201.4 requests.packages.urllib3.connectionpool: DEBUG: "POST /v2.0/subnets/ HTTP/1.1" 201 None requests.packages.urllib3.connectionpool: INFO: * Starting new HTTPS connection (1): 192.168.201.4 requests.packages.urllib3.connectionpool: DEBUG: "POST /v2.0/ports/ HTTP/1.1" 201 None requests.packages.urllib3.connectionpool: INFO: * Starting new HTTPS connection (1): 192.168.201.4 requests.packages.urllib3.connectionpool: DEBUG: "GET /v2.0/networks/ HTTP/1.1" 200 None requests.packages.urllib3.connectionpool: INFO: * Starting new HTTPS connection (1): 192.168.201.4 requests.packages.urllib3.connectionpool: DEBUG: "GET /v2.0/ports/ HTTP/1.1" 200 None requests.packages.urllib3.connectionpool: INFO: * Starting new HTTPS connection (1): 192.168.201.4 requests.packages.urllib3.connectionpool: DEBUG: "GET /v2.0/subnets/ HTTP/1.1" 200 None --------------------- >> end captured logging << --------------------- </error> -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted

7 17

[VDSM] upgrading pylint - new errors
by Nir Soffer 28 Dec '17

28 Dec '17

I'm trying to upgrade pylint to latest so we can enjoy latest fixes like this: https://github.com/PyCQA/pylint/issues/1736 Now we have some new errors, please check. ************* Module vdsm.clientIF*00:06:53.857* *E*:588,16: *Possible unbalanced tuple unpacking with sequence: left side has 2 label(s), right side has 0 value(s)* (*unbalanced-tuple-unpacking*) 587 if eventid == libvirt.VIR_DOMAIN_EVENT_ID_LIFECYCLE: 588 event, detail = args[:-1] 589 v.onLibvirtLifecycleEvent(event, detail, None) Code is indeed incorrect, should be: event, detail = args[:2] *00:06:53.859* *E*:593,16: *Possible unbalanced tuple unpacking with sequence: left side has 1 label(s), right side has 0 value(s)* (*unbalanced-tuple-unpacking*)*00:06:53.861* *E*:596,16: *Possible unbalanced tuple unpacking with sequence: left side has 4 label(s), right side has 0 value(s)* (*unbalanced-tuple-unpacking*)*00:06:53.863* *E*:599,16: *Possible unbalanced tuple unpacking with sequence: left side has 5 label(s), right side has 0 value(s)* (*unbalanced-tuple-unpacking*)*00:06:53.867* *E*:610,16: *Possible unbalanced tuple unpacking with sequence: left side has 1 label(s), right side has 0 value(s)* (*unbalanced-tuple-unpacking*)*00:06:53.869* *E*:615,16: *Possible unbalanced tuple unpacking with sequence: left side has 1 label(s), right side has 0 value(s)* (*unbalanced-tuple-unpacking*)*00:06:53.872* *E*:618,16: *Possible unbalanced tuple unpacking with sequence: left side has 4 label(s), right side has 0 value(s)* (*unbalanced-tuple-unpacking*)*00:06:53.873* ************* Module vdsm.v2v*00:06:53.874* *E*:1368,27: *Instance of 'closing' has no 'read' member* (*no-member*)*00:06:53.876* ************* Module vdsm.tool.configurator*00:06:53.878* *E*:118,12: *No value for argument 'action' in function call* (*no-value-for-parameter*)*00:06:53.880* *E*:158,12: *No value for argument 'action' in function call* (*no-value-for-parameter*)*00:06:53.881* *E*:193,12: *No value for argument 'action' in function call* (*no-value-for-parameter*)*00:06:53.883* *E*:215,12: *No value for argument 'action' in function call* (*no-value-for-parameter*)*00:06:53.885* ************* Module vdsm.virt.vm_migrate_hook*00:06:53.886* *E*:199, 4: *No value for argument 'domain' in function call* (*no-value-for-parameter*)*00:06:53.888* *E*:199, 4: *No value for argument 'event' in function call* (*no-value-for-parameter*)*00:06:53.890* *E*:199, 4: *No value for argument 'phase' in function call* (*no-value-for-parameter*)*00:06:53.892* ************* Module vdsm.network.netlink.monitor*00:06:53.893* *E*:172,58: *Instance of 'closing' has no 'poll' member* (*no-member*)

3 7

vdsm: AttributeError: 'NoneType' object has no attribute 'wrap_command'
by Yaniv Kaul 28 Dec '17

28 Dec '17

Just saw this on[1]: 2017-12-28 10:09:24,980-0500 INFO (MainThread) [vdsm.api] FINISH prepareForShutdown return=None from=internal, task_id=1a83a4d3-43e3-4833-883b-dfd2fe4d76be (api:52) 2017-12-28 10:09:24,980-0500 INFO (MainThread) [vds] Stopping threads (vdsmd:159) 2017-12-28 10:09:24,980-0500 INFO (MainThread) [vds] Exiting (vdsmd:170) 2017-12-28 10:09:25,011-0500 INFO (mailbox-hsm) [storage.MailBox.HsmMailMonitor] HSM_MailboxMonitor - Incoming mail monitoring thread stopped, clearing outgoing mail (mailbox:511) 2017-12-28 10:09:25,011-0500 INFO (mailbox-hsm) [storage.MailBox.HsmMailMonitor] HSM_MailMonitor sending mail to SPM - ['/usr/bin/dd', 'of=/rhev/data-center/9b97451a-0312-4c69-85e2-f86d6d273636/mastersd/dom_md/inbox', 'iflag=fullblock', 'oflag=direct', 'conv=notrunc', 'bs=4096', 'count=1', 'seek=1'] (mailbox:387) 2017-12-28 10:09:25,012-0500 ERROR (mailbox-hsm) [storage.MailBox.HsmMailMonitor] FINISH thread <Thread(mailbox-hsm, started daemon 139968009594624)> failed (concurrent:201) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/common/concurrent.py", line 194, in run ret = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/storage/mailbox.py", line 514, in _run self._sendMail() # Clear outgoing mailbox File "/usr/lib/python2.7/site-packages/vdsm/storage/mailbox.py", line 394, in _sendMail _mboxExecCmd(self._outCmd, data=self._outgoingMail) File "/usr/lib/python2.7/site-packages/vdsm/storage/mailbox.py", line 84, in _mboxExecCmd return misc.execCmd(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/common/commands.py", line 53, in execCmd command = cmdutils.wrap_command(command, with_ioclass=ioclass, AttributeError: 'NoneType' object has no attribute 'wrap_command' 2017-12-28 10:09:28,965-0500 INFO (MainThread) [vds] (PID: 23232) I am the actual vdsm 4.20.9-84.git615770f.el7.centos lago-basic-suite-master-host-0 (3.10.0-693.2.2.el7.x86_64) (vdsmd:148) 2017-12-28 10:09:28,966-0500 INFO (MainThread) [vds] VDSM will run with cpu affinity: frozenset([1]) (vdsmd:254) 2017-12-28 10:09:28,970-0500 INFO (MainThread) [storage.HSM] START HSM init (hsm:366) [1] http://jenkins.ovirt.org/job/ovirt-system-tests_master_check-patch-el7-x86_…

3 2

User is not authorized to perform this action. - trying to add SSH Public Key for a user
by Yaniv Kaul 28 Dec '17

28 Dec '17

I'm following the example[1] and getting an error: User is not authorized to perform this action. What permission do I need (I'm using admin@internal) in order to do this? Engine.log: 2017-12-28 07:25:35,571-05 WARN [org.ovirt.engine.core.bll.AddUserProfileCommand] (default task-13) [5af96d04-f81d-4c76-9f06-ee03a12e2f71] Validation of action 'AddUserProfile' failed for user admin@internal-authz. Reasons: VAR__ACTION__ADD,VAR__TYPE__USER_PROFILE,USER_NOT_AUTHORIZED_TO_PERFORM_ACTION 2017-12-28 07:25:35,572-05 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-13) [5af96d04-f81d-4c76-9f06-ee03a12e2f71] method: runAction, params: [AddUserProfile, UserProfileParameters:{commandId='a57680f0-3926-4808-8452-ea8d67b076a3', user='null', commandType='Unknown'}], timeElapsed: 41ms 2017-12-28 07:25:35,577-05 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-13) [] Operation Failed: [User is not authorized to perform this action.] TIA, Y. [1] https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/add_user…

2 1

node zero Networking
by Yedidyah Bar David 28 Dec '17

28 Dec '17

Hi all, I spent quite some time trying to deploy node zero, trying to look at https://bugzilla.redhat.com/show_bug.cgi?id=1528253 , and always fail around the end, with: ERROR fatal: [localhost]: FAILED! => {"attempts": 50, "changed": true, "cmd": "ip rule list | grep ovirtmgmt | sed s/\\\\[.*\\\\]\\ //g | awk '{ print $9 }'", "delta": "0:00:00.008292", "end": "2017-12-25 11:51:39.146800", "rc": 0, "start": "2017-12-25 11:51:39.138508", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []} ERROR Failed to execute stage 'Closing up': Failed executing ansible-playbook ERROR Hosted Engine deployment failed: this system is not reliable, please check the issue,fix and redeploy I use the following setup: I have a libvirt vm on my laptop, with a single virtual nic eth0. This nic is connected to a bridge called intbr on my laptop. This bridge has no access to outside, and VMs on it have no default route. There is a local dhcp+dns serving this bridge, using the address range 192.168.3.0/24. The vm serves as a nested-kvm hosted-engine host. eth0 gets a static IP address 192.168.3.42 from dhcpd. There is also (didn't check who/what exactly creates it, I think it's libvirt's default) a bridge there called virbr0. virbr0 has IP address 192.168.122.1/24 . When I deploy HE, the engine machine gets also a single virtual nic, which is connected to virbr0, and gets an IP address in that range (192.168.122.85, currently). deploy fails when running the task: - name: Get ovirtmgmt route table id shell: ip rule list | grep ovirtmgmt | sed s/\\[.*\\]\ //g | awk '{ print $9 }' register: ovirtmgmt_table_id until: ovirtmgmt_table_id.stdout_lines|length >= 1 retries: 50 delay: 10 changed_when: True The output of 'ip rule list' is: 0: from all lookup local 32766: from all lookup main 32767: from all lookup default So does not include 'ovirtmgmt'. I do have: # brctl show bridge name bridge id STP enabled interfaces ;vdsmdummy; 8000.000000000000 no ovirtmgmt 8000.06d1bd012412 no eth0 virbr0 8000.525400012499 yes virbr0-nic vnet0 And: # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovirtmgmt state UP qlen 1000 link/ether 06:d1:bd:01:24:12 brd ff:ff:ff:ff:ff:ff 18: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000 link/ether 52:54:00:01:24:99 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 19: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 1000 link/ether 52:54:00:01:24:99 brd ff:ff:ff:ff:ff:ff 20: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master virbr0 state UNKNOWN qlen 1000 link/ether fe:d1:bd:01:24:04 brd ff:ff:ff:ff:ff:ff inet6 fe80::fcd1:bdff:fe01:2404/64 scope link valid_lft forever preferred_lft forever 21: ;vdsmdummy;: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 1e:1b:84:c2:51:ff brd ff:ff:ff:ff:ff:ff 22: ovirtmgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000 link/ether 06:d1:bd:01:24:12 brd ff:ff:ff:ff:ff:ff inet 192.168.3.42/24 brd 192.168.3.255 scope global dynamic ovirtmgmt valid_lft 70927sec preferred_lft 70927sec inet6 fe80::4d1:bdff:fe01:2412/64 scope link valid_lft forever preferred_lft forever (And of course told deploy that I want to use eth0). Questions: 1. Did this already work for anyone at all? If so, can you please share details? Specifically, how was networking configured? 2. It might be that my problems are due to not having a (default) route for ovirtmgmt bridge/network. If so, then I consider this a bug, but do not mind configuring one for now. 3. All of the relevant section of the playbook has a comment preceding it: # all of the next is a workaroud for the network issue, vdsm installation breaks the routing and it needs to be fixed # once we'll fix the host installation it could be removed Do we have specific details/bug/whatever about the problem we are working around? Perhaps it's already solved and I can try to remove this part? 4. Both now (with (3.) being worked around) and eventually (when it's (what?) fixed), how should this work? Should the engine local vm indeed start connected to virbr0, and then move to ovirtmgmt? Or only the new engine vm (residing on the shared storage) should be in ovirtmgmt? 5. In particular, what should I supply for the "engine fqdn", and what should it resolve to, both in the beginning an eventually? Thanks, -- Didi

1 1

oVirt System Test configuration
by Sandro Bonazzola 27 Dec '17

27 Dec '17

Hi, I'd like to discuss what's being tested by oVirt System Test. I'm investigating on a sanlock issue that affects hosted engine hc suite. I installed a CentOS minimal VM and set repositories as in http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-master/128/a… Upgrade from CentOS 1708 (7.4) minimal is: Aggiornamento: bind-libs-lite x86_64 32:9.9.4-51.el7_4.1 centos-updates-el7 733 k bind-license noarch 32:9.9.4-51.el7_4.1 centos-updates-el7 84 k nss x86_64 3.28.4-15.el7_4 centos-updates-el7 849 k nss-softokn x86_64 3.28.3-8.el7_4 centos-updates-el7 310 k nss-softokn-freebl x86_64 3.28.3-8.el7_4 centos-updates-el7 214 k nss-sysinit x86_64 3.28.4-15.el7_4 centos-updates-el7 60 k nss-tools x86_64 3.28.4-15.el7_4 centos-updates-el7 501 k selinux-policy noarch 3.13.1-166.el7_4.7 centos-updates-el7 437 k selinux-policy-targeted noarch 3.13.1-166.el7_4.7 centos-updates-el7 6.5 M systemd x86_64 219-42.el7_4.4 centos-updates-el7 5.2 M systemd-libs x86_64 219-42.el7_4.4 centos-updates-el7 376 k systemd-sysv x86_64 219-42.el7_4.4 centos-updates-el7 70 k Enabling the CentOS repos: grub2 x86_64 1:2.02-0.65.el7.centos.2 updates 29 k in sostituzione di grub2.x86_64 1:2.02-0.64.el7.centos grub2-tools x86_64 1:2.02-0.65.el7.centos.2 updates 1.8 M in sostituzione di grub2-tools.x86_64 1:2.02-0.64.el7.centos grub2-tools-extra x86_64 1:2.02-0.65.el7.centos.2 updates 993 k in sostituzione di grub2-tools.x86_64 1:2.02-0.64.el7.centos grub2-tools-minimal x86_64 1:2.02-0.65.el7.centos.2 updates 170 k in sostituzione di grub2-tools.x86_64 1:2.02-0.64.el7.centos kernel x86_64 3.10.0-693.11.1.el7 updates 43 M Aggiornamento: NetworkManager x86_64 1:1.8.0-11.el7_4 updates 1.6 M NetworkManager-libnm x86_64 1:1.8.0-11.el7_4 updates 1.2 M NetworkManager-team x86_64 1:1.8.0-11.el7_4 updates 156 k NetworkManager-tui x86_64 1:1.8.0-11.el7_4 updates 224 k NetworkManager-wifi x86_64 1:1.8.0-11.el7_4 updates 184 k bash x86_64 4.2.46-29.el7_4 updates 1.0 M bind-libs-lite x86_64 32:9.9.4-51.el7_4.1 centos-updates-el7 733 k bind-license noarch 32:9.9.4-51.el7_4.1 centos-updates-el7 84 k binutils x86_64 2.25.1-32.base.el7_4.1 updates 5.4 M cpio x86_64 2.11-25.el7_4 updates 210 k cryptsetup-libs x86_64 1.7.4-3.el7_4.1 updates 223 k curl x86_64 7.29.0-42.el7_4.1 updates 267 k glibc x86_64 2.17-196.el7_4.2 updates 3.6 M glibc-common x86_64 2.17-196.el7_4.2 updates 11 M grub2-common noarch 1:2.02-0.65.el7.centos.2 updates 726 k grub2-pc x86_64 1:2.02-0.65.el7.centos.2 updates 29 k grub2-pc-modules noarch 1:2.02-0.65.el7.centos.2 updates 845 k iptables x86_64 1.4.21-18.2.el7_4 updates 428 k kernel-tools x86_64 3.10.0-693.11.1.el7 updates 5.1 M kernel-tools-libs x86_64 3.10.0-693.11.1.el7 updates 5.0 M kexec-tools x86_64 2.0.14-17.2.el7 updates 333 k kmod x86_64 20-15.el7_4.6 updates 120 k kmod-libs x86_64 20-15.el7_4.6 updates 50 k libblkid x86_64 2.23.2-43.el7_4.2 updates 176 k libcurl x86_64 7.29.0-42.el7_4.1 updates 219 k libgcc x86_64 4.8.5-16.el7_4.1 updates 98 k libgomp x86_64 4.8.5-16.el7_4.1 updates 154 k libmount x86_64 2.23.2-43.el7_4.2 updates 178 k libpciaccess x86_64 0.13.4-3.1.el7_4 updates 26 k libstdc++ x86_64 4.8.5-16.el7_4.1 updates 301 k libuuid x86_64 2.23.2-43.el7_4.2 updates 79 k ncurses x86_64 5.9-14.20130511.el7_4 updates 304 k ncurses-base noarch 5.9-14.20130511.el7_4 updates 68 k ncurses-libs x86_64 5.9-14.20130511.el7_4 updates 316 k nss x86_64 3.28.4-15.el7_4 centos-updates-el7 849 k nss-softokn x86_64 3.28.3-8.el7_4 centos-updates-el7 310 k nss-softokn-freebl x86_64 3.28.3-8.el7_4 centos-updates-el7 214 k nss-sysinit x86_64 3.28.4-15.el7_4 centos-updates-el7 60 k nss-tools x86_64 3.28.4-15.el7_4 centos-updates-el7 501 k openssh x86_64 7.4p1-13.el7_4 updates 509 k openssh-clients x86_64 7.4p1-13.el7_4 updates 654 k openssh-server x86_64 7.4p1-13.el7_4 updates 458 k python-gobject-base x86_64 3.22.0-1.el7_4.1 updates 294 k python-perf x86_64 3.10.0-693.11.1.el7 updates 5.1 M selinux-policy noarch 3.13.1-166.el7_4.7 centos-updates-el7 437 k selinux-policy-targeted noarch 3.13.1-166.el7_4.7 centos-updates-el7 6.5 M sudo x86_64 1.8.19p2-11.el7_4 updates 1.1 M systemd x86_64 219-42.el7_4.4 centos-updates-el7 5.2 M systemd-libs x86_64 219-42.el7_4.4 centos-updates-el7 376 k systemd-sysv x86_64 219-42.el7_4.4 centos-updates-el7 70 k tzdata noarch 2017c-1.el7 updates 468 k util-linux x86_64 2.23.2-43.el7_4.2 updates 2.0 M wpa_supplicant x86_64 1:2.6-5.el7_4.1 updates 1.2 M meaning this environement is not receiving updates to core packages like the kernel. Restricting to libvirt, with the repos used in the job libvirt packages doesn't even exists, making yum install libvirt just fail. I think you already know I'm against filtering packages from the repos even if I understand it saves a huge amount of space and download time. I may be wrong, but I tend to not trust OST results since it's not testing real life environments. Any chance we can improve OST to match what users are going to have on their systems? -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

6 14

upgrade_check and upgrade API calls (v4)
by Yaniv Kaul 26 Dec '17

26 Dec '17

I'm trying to check if a certain host can be upgraded. 1. I'm calling it through the host_service, something like: host_service = connection.system_service().hosts_service().host_service( host.id) is_upgrade = host_service.upgrade_check() To my surprise, is_upgrade is None. I expected a Boolean. 2. In addition, when trying to upgrade via: host_service.upgrade() I'm getting Operation Failed - and it complains there are no upgrades available. Alas, in the UI it shows that upgrades available and upgrade does work through the UI. Am I misusing the functions? (The host is a regular host, not ovirt-node btw). TIA, Y.

3 3

Memory size (1024MB) cannot exceed maximum memory size (0MB).] - when trying to create an instance type
by Yaniv Kaul 26 Dec '17

26 Dec '17

While trying to add an instance type, I fail with the error: Operation Failed". Fault detail is "[Cannot add Template. Memory size (1024MB) cannot exceed maximum memory size (0MB).] The code is taken from the example in the SDK, so I'm not sure what I'm doing wrong here. Code: instance_types_service.add( types.InstanceType( name='myinstancetype', description='My instance type', memory=1 * 2**30, high_availability=types.HighAvailability( enabled=True, ), cpu=types.Cpu( topology=types.CpuTopology( cores=2, sockets=2, ), ), ), ) engine.log: 2017-12-25 10:58:19,825-05 INFO [org.ovirt.engine.core.bll.AddVmTemplateCommand] (default task-13) [265ff704-d89f-471b-8207-fc0e1b8816fd] Lock Acquired to object 'EngineLock:{exclusiveLocks='[myinstancetype=TEMPLATE_NAME, 703e1265-e160-4a76-82e6-06974156b7b9=TEMPLATE]', sharedLocks='[]'}' 2017-12-25 10:58:19,831-05 WARN [org.ovirt.engine.core.bll.AddVmTemplateCommand] (default task-13) [265ff704-d89f-471b-8207-fc0e1b8816fd] Validation of action 'AddVmTemplate' failed for user admin@internal-authz. Reasons: VAR__ACTION__ADD,VAR__TYPE__VM_TEMPLATE,ACTION_TYPE_FAILED_MAX_MEMORY_CANNOT_BE_SMALLER_THAN_MEMORY_SIZE,$maxMemory 0,$memory 1024 2017-12-25 10:58:19,832-05 INFO [org.ovirt.engine.core.bll.AddVmTemplateCommand] (default task-13) [265ff704-d89f-471b-8207-fc0e1b8816fd] Lock freed to object 'EngineLock:{exclusiveLocks='[myinstancetype=TEMPLATE_NAME, 703e1265-e160-4a76-82e6-06974156b7b9=TEMPLATE]', sharedLocks='[]'}' 2017-12-25 10:58:19,839-05 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-13) [265ff704-d89f-471b-8207-fc0e1b8816fd] method: runAction, params: [AddVmTemplate, AddVmTemplateParameters:{commandId='179df9ed-209c-4882-a19a-b76a4fe1adb8', user='null', commandType='Unknown'}], timeElapsed: 33ms 2017-12-25 10:58:19,846-05 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-13) [] Operation Failed: [Cannot add Template. Memory size (1024MB) cannot exceed maximum memory size (0MB).] TIA, Y.

4 4

[ OST Failure Report ] [ oVirt master ] [ 2017-12-24 ] [add_hosts]
by Barak Korren 25 Dec '17

25 Dec '17

Test failed: [ 002_bootstrap.add_hosts ] Link to suspected patches: - Linked test is failing with the failing engine patch: https://gerrit.ovirt.org/#/c/85533/2 - Tests with engine patches had been failing since: https://gerrit.ovirt.org/#/c/85668/2 Link to Job: https://gerrit.ovirt.org/#/c/85668/2 Link to all logs: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4497/artifact… Error snippet from log: <error> 'Host lago-upgrade-from-release-suite-master-host0 is in non responsive state -------------------- >> begin captured logging << -------------------- ovirtlago.testlib: ERROR: * Unhandled exception in <function _host_is_up_4 at 0x45fb938> Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 219, in assert_equals_within res = func() File "/home/jenkins/workspace/ovirt-master_change-queue-tester/ovirt-system-tests/upgrade-from-release-suite-master/test-scenarios-after-upgrade/002_bootstrap.py", line 178, in _host_is_up_4 api_host.name)\nRuntimeError: Host lago-upgrade-from-release-suite-master-host0 is in non responsive state --------------------- >> end captured logging << --------------------- </error> For some reason there is no host-deploy log, so further analysis is difficult. -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted

3 7

ovirt 4.2 host not compatible
by Paul Dyer 24 Dec '17

24 Dec '17

Hi, I have upgraded to ovirt 4.2 without issue. But I cannot find a way to upgrade the host compatibility in the new OVirt Manager. I get this error when activiating the host... host parasol is compatible with versions (3.6,4.0,4.1) and cannot join Cluster Intel which is set to version 4.2. Thanks, Paul -- Paul Dyer, Mercury Consulting Group, RHCE 504-302-8750

3 5

when engine is running, then certs changed, will caused some problem?
by pengyixiang 22 Dec '17

22 Dec '17

------=_Part_19017_566575222.1513904421765 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 aGksIGV2ZXJ5b25lIQoKCiAgIGZpcnN0LCB3ZSBjYWxsIGdldFJlYWN0b3IgaW4gbmV3IFNjZW5h cmlvQ2xpZW50KCkuCgoKcHVibGljIFNjZW5hcmlvQ2xpZW50KFN0cmluZyBob3N0bmFtZSwgaW50 IHBvcnQpIHRocm93cyBDbGllbnRDb25uZWN0aW9uRXhjZXB0aW9uIHsKdGhpcy5yZWFjdG9yID0g UmVhY3RvckZhY3RvcnkuZ2V0UmVhY3RvcihQcm92aWRlckZhY3RvcnkuZ2V0UHJvdmlkZXIoKSwg UmVhY3RvclR5cGUuU1RPTVApOwpmaW5hbCBSZWFjdG9yQ2xpZW50IGNsaWVudCA9IHRoaXMucmVh Y3Rvci5jcmVhdGVDbGllbnQoaG9zdG5hbWUsIHBvcnQpOwogICAgY2xpZW50LnNldENsaWVudFBv bGljeShuZXcgRGVmYXVsdFN0b21wQ29ubmVjdGlvblBvbGljeSgpKTsKdGhpcy53b3JrZXIgPSBS ZWFjdG9yRmFjdG9yeS5nZXRXb3JrZXIoUEFSQUxMRUxJU00pOwp0aGlzLmpzb25DbGllbnQgPSB0 aGlzLndvcmtlci5yZWdpc3RlcihjbGllbnQpOwp0aGlzLmpzb25DbGllbnQuc2V0UmV0cnlQb2xp Y3kobmV3IERlZmF1bHRTdG9tcENsaWVudFBvbGljeSgpKTsKCn0KCgphbmQgUmVhY3RvckZhY3Rv cnkuZ2V0UmVhY3RvciB3aWxsIGNhbGwgZ2V0U3NsU3RvbXBSZWFjdG9yIHRoYXQgaXMgYSBzdGF0 aWMgd2F5IGluIFJlYWN0b3JGYWN0b3J5LgoKCgpwcml2YXRlIHN0YXRpYyBSZWFjdG9yIGdldFNz bFN0b21wUmVhY3RvcihNYW5hZ2VyUHJvdmlkZXIgcHJvdmlkZXIpIHRocm93cyBDbGllbnRDb25u ZWN0aW9uRXhjZXB0aW9uIHsKaWYgKHNzbFN0b21wUmVhY3RvciAhPSBudWxsKSB7CnJldHVybiBz c2xTdG9tcFJlYWN0b3I7CiAgICB9CnN5bmNocm9uaXplZCAoUmVhY3RvckZhY3RvcnkuY2xhc3Mp IHsKaWYgKHNzbFN0b21wUmVhY3RvciAhPSBudWxsKSB7CnJldHVybiBzc2xTdG9tcFJlYWN0b3I7 CiAgICAgICAgfQp0cnkgewpzc2xTdG9tcFJlYWN0b3IgPSBuZXcgU1NMU3RvbXBSZWFjdG9yKHBy b3ZpZGVyLmdldFNTTENvbnRleHQoKSk7CiAgICAgICAgfSBjYXRjaCAoSU9FeGNlcHRpb24gfCBH ZW5lcmFsU2VjdXJpdHlFeGNlcHRpb24gZSkgewp0aHJvdyBuZXcgQ2xpZW50Q29ubmVjdGlvbkV4 Y2VwdGlvbihlKTsKICAgICAgICB9CiAgICB9CnJldHVybiBzc2xTdG9tcFJlYWN0b3I7Cn0KCmlm IHdlIGRldGVybWluZSAic3NsU3RvbXBSZWFjdG9yICE9IG51bGwiIG1heSBjYXVzZWQgaWYgZW5n aW5lIGlzIHJ1bm5pbmcsIHRoZW4gZW5naW5lLnAxMiBjaGFuZ2VkLCBidXQgd2UKdXNlIG9sZCBj ZXJ0cyBhbmQga2V5cywgd2lsbCB0aGF0PwoKCgoK ------=_Part_19017_566575222.1513904421765 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyBi YWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7 Ij5oaSwgZXZlcnlvbmUhPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OiBib2xkOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IGNvbG9yOiByZ2Io MCwgMCwgMCk7Ij48YnI+PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQt Y29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgZm9udC13ZWlnaHQ6IGJvbGQ7IGNvbG9yOiByZ2Io MCwgMCwgMCk7Ij4mbmJzcDsmbmJzcDsgZmlyc3QsIHdlIGNhbGwgZ2V0UmVhY3RvciBpbiBuZXcg U2NlbmFyaW9DbGllbnQoKS48L3NwYW4+PC9kaXY+PGRpdj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MDA4MDtmb250LXdlaWdodDpib2xkOyI+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxl PSJjb2xvcjojMDAwMDgwO2ZvbnQtd2VpZ2h0OmJvbGQ7Ij5wdWJsaWMgPC9zcGFuPlNjZW5hcmlv Q2xpZW50KFN0cmluZyBob3N0bmFtZSwgPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwODA7Zm9udC13 ZWlnaHQ6Ym9sZDsiPmludCA8L3NwYW4+cG9ydCkgPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwODA7 Zm9udC13ZWlnaHQ6Ym9sZDsiPnRocm93cyA8L3NwYW4+Q2xpZW50Q29ubmVjdGlvbkV4Y2VwdGlv biB7PC9kaXY+PHByZSBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjojZmZmZmZmO2NvbG9yOiMwMDAw MDA7Zm9udC1mYW1pbHk6J0RlamFWdSBTYW5zIE1vbm8nO2ZvbnQtc2l6ZToxMS4zcHQ7Ij4gICAg PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwODA7Zm9udC13ZWlnaHQ6Ym9sZDsiPnRoaXM8L3NwYW4+ LjxzcGFuIHN0eWxlPSJjb2xvcjojNjYwZTdhO2ZvbnQtd2VpZ2h0OmJvbGQ7Ij5yZWFjdG9yIDwv c3Bhbj49IFJlYWN0b3JGYWN0b3J5LjxzcGFuIHN0eWxlPSJmb250LXN0eWxlOml0YWxpYzsiPmdl dFJlYWN0b3I8L3NwYW4+KFByb3ZpZGVyRmFjdG9yeS48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTpp dGFsaWM7Ij5nZXRQcm92aWRlcjwvc3Bhbj4oKSwgUmVhY3RvclR5cGUuPHNwYW4gc3R5bGU9ImNv bG9yOiM2NjBlN2E7Zm9udC13ZWlnaHQ6Ym9sZDtmb250LXN0eWxlOml0YWxpYzsiPlNUT01QPC9z cGFuPik7PGJyPiAgICA8c3BhbiBzdHlsZT0iY29sb3I6IzAwMDA4MDtmb250LXdlaWdodDpib2xk OyI+ZmluYWwgPC9zcGFuPlJlYWN0b3JDbGllbnQgY2xpZW50ID0gPHNwYW4gc3R5bGU9ImNvbG9y OiMwMDAwODA7Zm9udC13ZWlnaHQ6Ym9sZDsiPnRoaXM8L3NwYW4+LjxzcGFuIHN0eWxlPSJjb2xv cjojNjYwZTdhO2ZvbnQtd2VpZ2h0OmJvbGQ7Ij5yZWFjdG9yPC9zcGFuPi5jcmVhdGVDbGllbnQo aG9zdG5hbWUsIHBvcnQpOzxicj4gICAgY2xpZW50LnNldENsaWVudFBvbGljeSg8c3BhbiBzdHls ZT0iY29sb3I6IzAwMDA4MDtmb250LXdlaWdodDpib2xkOyI+bmV3IDwvc3Bhbj5EZWZhdWx0U3Rv bXBDb25uZWN0aW9uUG9saWN5KCkpOzxicj4gICAgPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwODA7 Zm9udC13ZWlnaHQ6Ym9sZDsiPnRoaXM8L3NwYW4+LjxzcGFuIHN0eWxlPSJjb2xvcjojNjYwZTdh O2ZvbnQtd2VpZ2h0OmJvbGQ7Ij53b3JrZXIgPC9zcGFuPj0gUmVhY3RvckZhY3RvcnkuPHNwYW4g c3R5bGU9ImZvbnQtc3R5bGU6aXRhbGljOyI+Z2V0V29ya2VyPC9zcGFuPig8c3BhbiBzdHlsZT0i Y29sb3I6IzY2MGU3YTtmb250LXdlaWdodDpib2xkO2ZvbnQtc3R5bGU6aXRhbGljOyI+UEFSQUxM RUxJU008L3NwYW4+KTs8YnI+ICAgIDxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMDgwO2ZvbnQtd2Vp Z2h0OmJvbGQ7Ij50aGlzPC9zcGFuPi48c3BhbiBzdHlsZT0iY29sb3I6IzY2MGU3YTtmb250LXdl aWdodDpib2xkOyI+anNvbkNsaWVudCA8L3NwYW4+PSA8c3BhbiBzdHlsZT0iY29sb3I6IzAwMDA4 MDtmb250LXdlaWdodDpib2xkOyI+dGhpczwvc3Bhbj4uPHNwYW4gc3R5bGU9ImNvbG9yOiM2NjBl N2E7Zm9udC13ZWlnaHQ6Ym9sZDsiPndvcmtlcjwvc3Bhbj4ucmVnaXN0ZXIoY2xpZW50KTs8YnI+ ICAgIDxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMDgwO2ZvbnQtd2VpZ2h0OmJvbGQ7Ij50aGlzPC9z cGFuPi48c3BhbiBzdHlsZT0iY29sb3I6IzY2MGU3YTtmb250LXdlaWdodDpib2xkOyI+anNvbkNs aWVudDwvc3Bhbj4uc2V0UmV0cnlQb2xpY3koPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwODA7Zm9u dC13ZWlnaHQ6Ym9sZDsiPm5ldyA8L3NwYW4+RGVmYXVsdFN0b21wQ2xpZW50UG9saWN5KCkpOzxi cj48L3ByZT48ZGl2Pn08L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PmFuZCBSZWFjdG9yRmFjdG9y eS5nZXRSZWFjdG9yIHdpbGwgY2FsbCBnZXRTc2xTdG9tcFJlYWN0b3IgdGhhdCBpcyBhIHN0YXRp YyB3YXkgaW4gUmVhY3RvckZhY3RvcnkuPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHBy ZSBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjojZmZmZmZmO2NvbG9yOiMwMDAwMDA7Zm9udC1mYW1p bHk6J0RlamFWdSBTYW5zIE1vbm8nO2ZvbnQtc2l6ZToxMS4zcHQ7Ij48c3BhbiBzdHlsZT0iY29s b3I6IzAwMDA4MDtmb250LXdlaWdodDpib2xkOyI+cHJpdmF0ZSBzdGF0aWMgPC9zcGFuPlJlYWN0 b3IgZ2V0U3NsU3RvbXBSZWFjdG9yKE1hbmFnZXJQcm92aWRlciBwcm92aWRlcikgPHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDAwODA7Zm9udC13ZWlnaHQ6Ym9sZDsiPnRocm93cyA8L3NwYW4+Q2xpZW50 Q29ubmVjdGlvbkV4Y2VwdGlvbiB7PGJyPiAgICA8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigyNTUs IDAsIDApOyI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMjU1LCAwLCAwKTsgZm9udC13ZWlnaHQ6 IGJvbGQ7Ij5pZiA8L3NwYW4+KDxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDI1NSwgMCwgMCk7IGZv bnQtc3R5bGU6IGl0YWxpYzsiPnNzbFN0b21wUmVhY3RvciA8L3NwYW4+IT0gPHNwYW4gc3R5bGU9 ImNvbG9yOiByZ2IoMjU1LCAwLCAwKTsgZm9udC13ZWlnaHQ6IGJvbGQ7Ij5udWxsPC9zcGFuPikg ezxicj4gICAgICAgIDxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDI1NSwgMCwgMCk7IGZvbnQtd2Vp Z2h0OiBib2xkOyI+cmV0dXJuIDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigyNTUsIDAs IDApOyBmb250LXN0eWxlOiBpdGFsaWM7Ij5zc2xTdG9tcFJlYWN0b3I8L3NwYW4+Ozxicj4gICAg fTwvc3Bhbj48YnI+ICAgIDxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMDgwO2ZvbnQtd2VpZ2h0OmJv bGQ7Ij5zeW5jaHJvbml6ZWQgPC9zcGFuPihSZWFjdG9yRmFjdG9yeS48c3BhbiBzdHlsZT0iY29s b3I6IzAwMDA4MDtmb250LXdlaWdodDpib2xkOyI+Y2xhc3M8L3NwYW4+KSB7PGJyPiAgICAgICAg PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwODA7Zm9udC13ZWlnaHQ6Ym9sZDsiPmlmIDwvc3Bhbj4o PHNwYW4gc3R5bGU9ImNvbG9yOiM2NjBlN2E7Zm9udC1zdHlsZTppdGFsaWM7Ij5zc2xTdG9tcFJl YWN0b3IgPC9zcGFuPiE9IDxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMDgwO2ZvbnQtd2VpZ2h0OmJv bGQ7Ij5udWxsPC9zcGFuPikgezxicj4gICAgICAgICAgICA8c3BhbiBzdHlsZT0iY29sb3I6IzAw MDA4MDtmb250LXdlaWdodDpib2xkOyI+cmV0dXJuIDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 IzY2MGU3YTtmb250LXN0eWxlOml0YWxpYzsiPnNzbFN0b21wUmVhY3Rvcjwvc3Bhbj47PGJyPiAg ICAgICAgfTxicj4gICAgICAgIDxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMDgwO2ZvbnQtd2VpZ2h0 OmJvbGQ7Ij50cnkgPC9zcGFuPns8YnI+ICAgICAgICAgICAgPHNwYW4gc3R5bGU9ImNvbG9yOiM2 NjBlN2E7Zm9udC1zdHlsZTppdGFsaWM7Ij5zc2xTdG9tcFJlYWN0b3IgPC9zcGFuPj0gPHNwYW4g c3R5bGU9ImNvbG9yOiMwMDAwODA7Zm9udC13ZWlnaHQ6Ym9sZDsiPm5ldyA8L3NwYW4+U1NMU3Rv bXBSZWFjdG9yKHByb3ZpZGVyLmdldFNTTENvbnRleHQoKSk7PGJyPiAgICAgICAgfSA8c3BhbiBz dHlsZT0iY29sb3I6IzAwMDA4MDtmb250LXdlaWdodDpib2xkOyI+Y2F0Y2ggPC9zcGFuPihJT0V4 Y2VwdGlvbiB8IEdlbmVyYWxTZWN1cml0eUV4Y2VwdGlvbiBlKSB7PGJyPiAgICAgICAgICAgIDxz cGFuIHN0eWxlPSJjb2xvcjojMDAwMDgwO2ZvbnQtd2VpZ2h0OmJvbGQ7Ij50aHJvdyBuZXcgPC9z cGFuPkNsaWVudENvbm5lY3Rpb25FeGNlcHRpb24oZSk7PGJyPiAgICAgICAgfTxicj4gICAgfTxi cj4gICAgPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwODA7Zm9udC13ZWlnaHQ6Ym9sZDsiPnJldHVy biA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM2NjBlN2E7Zm9udC1zdHlsZTppdGFsaWM7Ij5z c2xTdG9tcFJlYWN0b3I8L3NwYW4+Ozxicj59PGJyPjxicj5pZiB3ZSBkZXRlcm1pbmUgInNzbFN0 b21wUmVhY3RvciAhPSBudWxsIiBtYXkgY2F1c2VkIGlmIGVuZ2luZSBpcyBydW5uaW5nLCB0aGVu IGVuZ2luZS5wMTIgY2hhbmdlZCwgYnV0IHdlPGJyPnVzZSBvbGQgY2VydHMgYW5kIGtleXMsIHdp bGwgdGhhdD88YnI+PGJyPjxicj48YnI+PGJyPjwvcHJlPjwvZGl2PjwvZGl2Pjxicj48YnI+PHNw YW4gdGl0bGU9Im5ldGVhc2Vmb290ZXIiPjxwPiZuYnNwOzwvcD48L3NwYW4+ ------=_Part_19017_566575222.1513904421765--

1 0

[Call for feedback] share also your successful upgrades experience
by Sandro Bonazzola 21 Dec '17

21 Dec '17

Hi, now that oVirt 4.2.0 has been released, we're starting to see some reports about issues that for now are related to not so common deployments. We'd also like to get some feedback from those who upgraded to this amazing release without any issue and add these positive feedback under our developers (digital) Christmas tree as a gift for the effort put in this release. Looking forward to your positive reports! Not having positive feedback? Let us know too! We are putting an effort in the next weeks to promptly assist whoever hit troubles during or after the upgrade. Let us know in this users(a)ovirt.org mailing list (preferred) or on IRC using irc.oftc.net server and #ovirt channel. We are also closely monitoring bugzilla.redhat.com for new bugs on oVirt project, so you can report issues there as well. Thanks, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

2 1

Planned restart of production services
by Evgheni Dereveanchin 21 Dec '17

21 Dec '17

Hi everyone, I will be restarting several production systems today to perform planned maintenance. The following services may be unreachable for some period of time: - gerrit.ovirt.org - code review - jenkins.ovirt.org - CI master It will not be possible to submit/review patches, clone repositories or run CI jobs during this period. I will announce you once the maintenance is complete. -- Regards, Evgheni Dereveanchin

1 1

oVirt 4.2.0 is now generally available
by Sandro Bonazzola 20 Dec '17

20 Dec '17

The oVirt project is excited to announce the general availability of oVirt 4.2.0, as of December 20, 2017. This release unleashes an altogether more powerful and flexible open source virtualization solution that encompasses over 1000 individual changes and a wide range of enhancements across the engine, storage, network, user interface, and analytics. Key features include: - A redesigned Administration Portal, with an improved user-interface - A new VM portal for non-admin users, for a more streamlined experience - High Performance virtual machine type, for easy optimization of high performance workloads. - oVirt metrics store, a new monitoring solution providing complete infrastructure visibility - Support for virtual machine connectivity via software-defined networks - oVirt now supports Nvidia vGPU - The ovirt-ansible-roles set of packages helps users with common administration tasks - Virt-v2v now supports Debian/Ubuntu and EL and Windows-based virtual machines For more information about these and other features, check out the oVirt 4.2.0 blog post <https://ovirt.org/blog/2017/12/ovirt-4.2.0-now-ga/>. This release is available now on x86_64 architecture for: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later This release supports Hypervisor Hosts on x86_64 and ppc64le (with 4.1 cluster compatibility only) architectures for: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later * oVirt Node 4.2 (available for x86_64 only) See the release notes [3] for installation / upgrade instructions and a list of new features and bugs fixed. If you’re managing more than one oVirt instance, OpenShift Origin or RDO we also recommend to try ManageIQ <http://manageiq.org/>. Notes: - oVirt Appliance is already available. - oVirt Node is already available [4] - oVirt Windows Guest Tools iso is already available [4] Additional Resources: * Read more about the oVirt 4.2.0 release highlights: http://www.ovirt.org/release/4.2.0/ * Get more oVirt project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] https://www.ovirt.org/community/ [2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt [3] http://www.ovirt.org/release/4.2.0/ [4] http://resources.ovirt.org/pub/ovirt-4.2/iso/ -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

1 0

oVirt 4.2.0 GA Go / No go
by Sandro Bonazzola 19 Dec '17

19 Dec '17

Hi, we released 4.2.0 RC3 yesterday and currently we don't have approved or proposed blockers. So maintainers, please give your Go / No go for releasing GA tomorrow, December 20th. Thanks, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

5 5

Migration failed (was: Change in ovirt-system-tests[master]: Run engine-setup with OTOPI_DEBUG=1)
by Yedidyah Bar David 19 Dec '17

19 Dec '17

On Mon, Dec 18, 2017 at 10:17 AM, Code Review <gerrit(a)ovirt.org> wrote: > Jenkins CI posted comments on this change. > > View Change > > Patch set 3:Continuous-Integration -1 > > Build Failed > > http://jenkins.ovirt.org/job/ovirt-system-tests_master_check-patch-el7-x86_… > : FAILURE Console output of above job says: 08:13:34 # migrate_vm: 08:16:37 * Collect artifacts: 08:16:40 * Collect artifacts: Success (in 0:00:03) 08:16:40 # migrate_vm: Success (in 0:03:06) 08:16:40 # Results located at /dev/shm/ost/deployment-basic-suite-master/default/006_migrations.py.junit.xml 08:16:40 @ Run test: 006_migrations.py: Success (in 0:03:50) 08:16:40 Error occured, aborting The file 006_migrations.py.junit.xml [1] says: <failure type="exceptions.AssertionError" message="False != True after 180 seconds"> Can someone please have a look? Thanks. As a side note, if indeed this is the cause for the failure for the job, it's misleading to say "migrate_vm: Success". [1] http://jenkins.ovirt.org/job/ovirt-system-tests_master_check-patch-el7-x86_… > > To view, visit change 85177. To unsubscribe, visit settings. > > Gerrit-Project: ovirt-system-tests > Gerrit-Branch: master > Gerrit-MessageType: comment > Gerrit-Change-Id: I7eb386744a2a2faf0acd734e0ba44be22dd590b5 > Gerrit-Change-Number: 85177 > Gerrit-PatchSet: 3 > Gerrit-Owner: Yedidyah Bar David <didi(a)redhat.com> > Gerrit-Reviewer: Dafna Ron <dron(a)redhat.com> > Gerrit-Reviewer: Eyal Edri <eedri(a)redhat.com> > Gerrit-Reviewer: Jenkins CI > Gerrit-Reviewer: Sandro Bonazzola <sbonazzo(a)redhat.com> > Gerrit-Reviewer: Yedidyah Bar David <didi(a)redhat.com> > Gerrit-Comment-Date: Mon, 18 Dec 2017 08:17:11 +0000 > Gerrit-HasComments: No -- Didi

6 9

oVirt 4.2.0 GA status
by Sandro Bonazzola 19 Dec '17

19 Dec '17

We have a proposed blocker for the release: 1527155 <https://bugzilla.redhat.com/show_bug.cgi?id=1527155> Infra vdsm Bindings-API igoihman(a)redhat.com NEW jsonrpc reconnect logic does not work and gets stuck <https://bugzilla.redhat.com/show_bug.cgi?id=1527155> urgent unspecified ovirt-4.2.0 04:30:30 Please review and either approve the blcoker or postpone to 4.2.1. Thanks, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

7 11

[ANN] oVirt 4.2.0 Third Candidate Release is now available for testing
by Sandro Bonazzola 18 Dec '17

18 Dec '17

The oVirt Project is pleased to announce the availability of the Third Candidate Release of oVirt 4.2.0, as of December 18th, 2017 This is pre-release software. This pre-release should not to be used in production. Please take a look at our community page[1] to learn how to ask questions and interact with developers and users. All issues or bugs should be reported via oVirt Bugzilla[2]. This release candidate includes fixes to the blocker bugs found while testing the second release candidate. This release is available now on x86_64 architecture for: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later * oVirt Node 4.2 (available for x86_64 only) See the release notes draft [3] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available. - oVirt Node is already available [4] Additional Resources: * Read more about the oVirt 4.2.0 release highlights: http://www.ovirt.org/release/4.2.0/ * Get more oVirt project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] https://www.ovirt.org/community/ [2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt [3] http://www.ovirt.org/release/4.2.0/ [4] http://resources.ovirt.org/pub/ovirt-4.2-pre/iso/ -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

1 0

Re: [ovirt-devel] oVirt 4.2.0 RC3 status
by Dan Kenigsberg 18 Dec '17

18 Dec '17

On Mon, Dec 18, 2017 at 3:57 PM, Meital Avital <mavital(a)redhat.com> wrote: > Nikolai succeed to reproduce the issue on the clean env, > That's not a precise reproduction, as Nikolai writes in comment 15 "It looks like different now." please see comments in *Bug 1525907* > <https://bugzilla.redhat.com/show_bug.cgi?id=1525907> - VDSM is in > recovery mode after a restart in fresh installation. > He also found another bug - *Bug 1527077* > <https://bugzilla.redhat.com/show_bug.cgi?id=1527077> - SHE deployment > fails over FC. > > Meital. > > On Mon, Dec 18, 2017 at 3:27 PM, Meital Avital <mavital(a)redhat.com> wrote: > >> Adding Ying to get her status >> >> On Mon, Dec 18, 2017 at 3:24 PM, Meital Avital <mavital(a)redhat.com> >> wrote: >> >>> *Update:* >>> Deployment with iSCSI succeed >>> >>> On Mon, Dec 18, 2017 at 2:26 PM, Meital Avital <mavital(a)redhat.com> >>> wrote: >>> >>>> Hi All, >>>> >>>> The status of old HE deploy for today is: >>>> Deployment with NFS succeed >>>> Deployment with Gluster succeed >>>> Artyom testing HE deployment with iSCSI - in progress >>>> According to this BZ1525907 - Nikolai trying again to deploy HE on the >>>> same host on clean env - we think that this issue related to those host, >>>> this is what we are trying to understand. >>>> I don't have the results yet, soon I will have them and I will update >>>> this thread. >>>> >>>> Thanks, >>>> Meital. >>>> >>>> On Mon, Dec 18, 2017 at 1:18 PM, Dan Kenigsberg <danken(a)redhat.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Mon, Dec 18, 2017 at 1:02 PM, Sandro Bonazzola <sbonazzo(a)redhat.com >>>>> > wrote: >>>>> >>>>>> >>>>>> >>>>>> 2017-12-18 8:37 GMT+01:00 Sandro Bonazzola <sbonazzo(a)redhat.com>: >>>>>> >>>>>>> >>>>>>> >>>>>>> 2017-12-18 8:29 GMT+01:00 Dan Kenigsberg <danken(a)redhat.com>: >>>>>>> >>>>>>>> On Mon, Dec 18, 2017 at 9:16 AM, Sandro Bonazzola < >>>>>>>> sbonazzo(a)redhat.com> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> according to https://bugzilla.redhat.com >>>>>>>>> /buglist.cgi?quicksearch=flag%3Ablocker%2B%20target_mileston >>>>>>>>> e%3Aovirt-4.2.0%20status%3Anew%2Cassigned%2Cpost%2Cmodified >>>>>>>>> we just need to rebuild VDSM to complete the acknowledged blockers. >>>>>>>>> >>>>>>>>> We still have a proposed blocker in NEW state according to >>>>>>>>> https://bugzilla.redhat.com/buglist.cgi?quicksearch=flag% >>>>>>>>> 3Ablocker%3F%20target_milestone%3Aovirt-4.2.0%20status%3Anew >>>>>>>>> %2Cassigned%2Cpost%2Cmodified >>>>>>>>> >>>>>>>>> 1525907 <https://bugzilla.redhat.com/show_bug.cgi?id=1525907> >>>>>>>>> Storage vdsm General danken(a)redhat.com NEW VDSM is in recovery >>>>>>>>> mode after a restart in fresh install... >>>>>>>>> <https://bugzilla.redhat.com/show_bug.cgi?id=1525907> urgent >>>>>>>>> urgent ovirt-4.2.0 Sat 18:12 >>>>>>>>> >>>>>>>>> Dan, please review, let us know if we have to block on this or if >>>>>>>>> we can postpone to 4.2.1. >>>>>>>>> >>>>>>>> >>>>>>>> I don't think it is for me to review. >>>>>>>> >>>>>>>> The bug is very confusing and sparse in information, but it seems >>>>>>>> to claim that self-hosted engine is not deployable. I think that it is for >>>>>>>> Simone to reply to that claim. Is it true? When? Do you think, like Adam, >>>>>>>> that this is a problem of host connectivity to its storage? >>>>>>>> >>>>>>> >>>>>>> Adam, Nir, Tal, Allon, can you please review? >>>>>>> >>>>>> >>>>>> Any update? >>>>>> >>>>> >>>>> +Meital. >>>>> >>>>> >>>> >>> >> >

2 2

oVirt 4.2.0 RC3 status
by Sandro Bonazzola 18 Dec '17

18 Dec '17

Hi, according to https://bugzilla.redhat.com/buglist.cgi?quicksearch=flag%3Ablocker%2B%20tar… we just need to rebuild VDSM to complete the acknowledged blockers. We still have a proposed blocker in NEW state according to https://bugzilla.redhat.com/buglist.cgi?quicksearch=flag%3Ablocker%3F%20tar… 1525907 <https://bugzilla.redhat.com/show_bug.cgi?id=1525907> Storage vdsm General danken(a)redhat.com NEW VDSM is in recovery mode after a restart in fresh install... <https://bugzilla.redhat.com/show_bug.cgi?id=1525907> urgent urgent ovirt-4.2.0 Sat 18:12 Dan, please review, let us know if we have to block on this or if we can postpone to 4.2.1. Yaniv Bronheim, if we don't need to block on this, please tag VDSM for release. -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

2 4

Testing
by Bernhard Seidl 18 Dec '17

18 Dec '17

Hi, I can put some effort in testing. In the last few days I used to test master branch snapshots and reported bugs. Are you ok with that, or should I focus on a different branch? Bernhard

3 2