Mailing-Lists upgrade
by Marc Dequènes (Duck)
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--
6 years, 10 months
[IMPORTANT] getting rid of our implementation of UUID generation in 4.2.1
by Eli Mesika
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
7 years, 1 month
sslStompReactor just created once, may cause engine failed to connect to new node
by pengyixiang
------=_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--
7 years, 2 months
oVirt s390x support - some questions for maintainers
by Barak Korren
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
7 years, 2 months
[ OST Failure Report ] [ oVirt master ] [ 24/12/2017 ] [use_ovn_provider]
by Barak Korren
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/artifa...
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 years, 2 months
[VDSM] upgrading pylint - new errors
by Nir Soffer
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*)
7 years, 2 months
vdsm: AttributeError: 'NoneType' object has no attribute 'wrap_command'
by Yaniv Kaul
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-x8...
7 years, 2 months
User is not authorized to perform this action. - trying to add SSH Public Key for a user
by Yaniv Kaul
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_us...
7 years, 2 months
node zero Networking
by Yedidyah Bar David
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
7 years, 2 months
oVirt System Test configuration
by Sandro Bonazzola
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...
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>
7 years, 2 months