May 2018 - Devel - oVirt List Archives

CentOS 7.5.1804 is now officially available
by Sandro Bonazzola 10 May '18

10 May '18

FYI, CentOS 7.5.1804 is now officially available. See announce here: https://lists.centos.org/pipermail/centos-announce/2018-May/022829.html Users: I suggest to upgrade in order to get latest features, fixes and security fixes. Just a note for ppc64le users, there's a known bug with libguestfs requiring qemu-kvm-ma instead of qemu-kvm that may cause upgrade issues. This should be fixed in next update which should land in CentOS in ~2 weeks. If you are still on 4.1, please change your centos repos to point to http://mirror.centos.org/centos/7.4.1708/ instead of http://mirror.centos.org/centos/7. Then please update to latest 4.1 and then to oVirt 4.2 + CentOS 7.5 as soon as you can. Devel: please cross check your jenkins jobs, especially those having to do something with 4.1 since CentOS 7.5 is not supporting oVirt 4.1 anymore. See above. Infra: please schedule a mass update of oVirt infrastructure to CentOS 7.5 + oVirt 4.2.3 ASAP. Thanks, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

3 5

Work-Around for Access Problem to resources.ovirt.org and jenkins.ovirt.org
by Anton Marchukov 09 May '18

09 May '18

Hello All. Please note that ovirt.org got HSTS setting enabled. The way this change was rolled was not authorised by us. The setting contains “includeSubDomains” parameter that ask browser to access all resources inside *.ovirt.org using https://. The problem is that not all resources on *.ovirt.org are https-enabled. And this will prevent you from being able to access http://resources.ovirt.org http://jenkins.ovirt.org This setting is cached in your browser and then applied with no exceptions even if you explicitly specify http:// the browser will rewrite to https and then connection to above mentioned resources will fail. The only immediate work-around for you is to clear the HSTS flag in your browser, please find the instructions for Firefox and Chrome [1]. Please note that you will get that setting back by visiting ovirt.org website until we clear it from there. We are currently working on this setting to be soften or disabled till all resources are https enabled that is also in progress. This is only related to access via the web browser. Accessing using yum or automated scripts should work fine as they usually do not observe and cache HSTS. Anton. [1] https://www.thesslstore.com/blog/clear-hsts-settings-chrome-firefox/

3 2

Please update your Fedora
by Sandro Bonazzola 09 May '18

09 May '18

Hi, if you're not yet on Fedora 28, please consider updating to it. On master we are aiming to support Fedora 28 and we are dismissing any older Fedora jobs in Jenkins soon. As a reminder Fedora 26 support is going to be EOL on Tuesday, May 29th, 2018. Thanks, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

2 1

Fwd: [JIRA] (OVIRT-2005) jira.ovirt.org redirect doesn't work anymore, redirects instead to https://jira.ovirt.org/ovirt.apps/
by Eyal Edri 09 May '18

09 May '18

FYI, It seems jira.ovirt.org redirect doesn't work, since we don't own the jira instance ( cloud provided by Attlasian ) it might be a change done on their side. We'll investigate and check possible solutions. Until then, please use the full URL for the JIRA instance - https://ovirt-jira.atlassian.net ---------- Forwarded message ---------- From: eyal edri (oVirt JIRA) <jira(a)ovirt-jira.atlassian.net> Date: Wed, May 9, 2018 at 10:11 AM Subject: [JIRA] (OVIRT-2005) jira.ovirt.org redirect doesn't work anymore, redirects instead to https://jira.ovirt.org/ovirt.apps/ To: infra(a)ovirt.org [ https://ovirt-jira.atlassian.net/browse/OVIRT-2005?page=com.atlassian.jira.… ] eyal edri updated OVIRT-2005: Epic Link: OVIRT-403 jira.ovirt.org redirect doesn't work anymore, redirects instead to https://jira.ovirt.org/ovirt.apps/ Key: OVIRT-2005 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2005 Project: oVirt - virtualization made easy Issue Type: Bug Reporter: eyal edri Assignee: infra Priority: High [~ederevea] any idea what could cause this? maybe Atlassian blocked us or IP was changed? cc [~ena(a)redhat.com] [~bkorren(a)redhat.com] — This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100083) _______________________________________________ Infra mailing list -- infra(a)ovirt.org To unsubscribe send an email to infra-leave(a)ovirt.org -- Eyal edri MANAGER RHV DevOps EMEA VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

1 0

oVirt Orb 4.2.3 is now available
by Sandro Bonazzola 09 May '18

09 May '18

oVirt Orb image has been updated with oVirt 4.2.3 content[1] oVirt Orb is a project that allows anyone to easily take an oVirt for a ride, test and play with it. See oVirt Orb documentation for using it[2] [1] http://resources.ovirt.org/pub/ovirt-4.2/ovirt-orb/ [2] https://ovirt.org/documentation/ovirt-orb/ -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

3 5

Tracking down a vdsm memory leak
by Chris Adams 08 May '18

08 May '18

I have a problem with a memory leak in vdsm. I have a dev cluster that right now is: - two nodes - CentOS 7.4 (up to date) - oVirt 4.2.2 (installed as 3.5 and upgraded version by version) - hosted engine (no other running VM at the moment) - iSCSI storage I have a script that writes the vdsm RSS to a file every five minutes, and on the node holding the hosted engine, vdsm RSS grows around 300-1500KB every snapshot. I maintain several oVirt clusters for others, and they all seem to have this problem. The production clusters are all still on oVirt 4.1, but they all have this problem too, so I guess it is something about how I set them up? On a couple I just checked, the vdsm RSS is over 1G. Any tips on instrumenting vdsm to track this down? I am unfortunately only passingly familiar with python (I can make small changes, but not knowledgeable enough to figure this out). -- Chris Adams <cma(a)cmadams.net>

3 8

oVirt messages from engine to vdsm
by Anastasiya Ruzhanskaya 08 May '18

08 May '18

Hello everyone! Currently I want to determine what information is included in messages passing from oVirt engine to VDSM on ovirt-node. I made up a really simple configuration with one VM representing engine, another - node, a managed to successfully launch a single VM on this node. However, I have chosen to configure everything automatically. Currently traffic is encrypted with default certificates. So, there are three options for me and no one of them really works. 1) Find the format of messages ( what the fields are, session id for example) in docs, but I didn't manage to find it; 2) Use wireshark to decrypt the traffic and the apply maybe a json -dissector to the decrypted data. I have tried many solutions ( thanks god I have rsa private and public keys but there is another session key which is generated every time engine starts to communicate with vdsm, which I cannot get with the help of sslkeylog file or ld_preload technology. Maybe someone knows the exact methodology how to do this correctly? 3) Turn off ssl in oVirt. It is simple to do that for vdsm, but for engine, according to answers on oVirt site, I should do 2 requests to the database. I was really surprised that psql was not installed by oVirt on my system. How did it then created a default database? ( I have chosen to create all locally and with default configurations). I mean these two commands : https://www.ovirt.org/develop/ developer-guide/vdsm/connecting-development-vdsm-to-engine/ . I have a following error there : psql: FATAL: Peer authentication failed for user "engine" Could you please guide my what method is the best and how should I correct my faults there?

3 10

OST: oVirt version used in basic-suite-4.2
by Milan Zamazal 07 May '18

07 May '18

Hi, I wonder why is ovirt-4.2 repo, rather than ovirt-4.2-snapshot or so, used in reposync-config for basic-suite-4.2? Packages in ovirt-4.2 are relatively old and the suite may fail on bugs that are already fixed. Shouldn't a more up-to-date repo be used in basic-suite-4.2? Thanks, Milan

3 3

ovirt-host-deploy and python3
by Tomáš Golembiovský 07 May '18

07 May '18

Hi, I'm trying to reinstall a CentOS host (using master-snapshot) and I noticed otopi is trying to use python3 while the ovirt-host-deploy is not yet fully python3 compatible: > 2018-05-03 21:35:56,855+0200 DEBUG otopi.plugins.otopi.system.info info._init:39 SYSTEM INFORMATION - BEGIN > 2018-05-03 21:35:56,855+0200 DEBUG otopi.plugins.otopi.system.info info._init:40 executable /bin/python3 > 2018-05-03 21:35:56,855+0200 DEBUG otopi.plugins.otopi.system.info info._init:41 python version 3.4.8 (default, Mar 23 2018, 10:04:27) > [GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] > 2018-05-03 21:35:56,855+0200 DEBUG otopi.plugins.otopi.system.info info._init:42 python /bin/python3 > 2018-05-03 21:35:56,856+0200 DEBUG otopi.plugins.otopi.system.info info._init:43 platform linux > 2018-05-03 21:35:56,856+0200 DEBUG otopi.plugins.otopi.system.info info._init:44 distribution ('CentOS Linux', '7.4.1708', 'Core') > 2018-05-03 21:35:56,856+0200 DEBUG otopi.plugins.otopi.system.info info._init:45 host 'ovirt-host2' > 2018-05-03 21:35:56,856+0200 DEBUG otopi.plugins.otopi.system.info info._init:51 uid 0 euid 0 gid 0 egid 0 > 2018-05-03 21:35:56,856+0200 DEBUG otopi.plugins.otopi.system.info info._init:53 SYSTEM INFORMATION - END and then later: > 2018-05-03 21:35:56,912+0200 DEBUG otopi.context context._executeMethod:128 Stage init METHOD otopi.plugins.ovirt_host_deploy.node.detect.Plugin._init > 2018-05-03 21:35:56,914+0200 DEBUG otopi.context context._executeMethod:143 method exception > Traceback (most recent call last): > File "/tmp/ovirt-a0GNITSwX9/pythonlib/otopi/context.py", line 133, in _executeMethod > method['method']() > File "/tmp/ovirt-a0GNITSwX9/otopi-plugins/ovirt-host-deploy/node/detect.py", line 131, in _init > odeploycons.FileLocations.OVIRT_NODE_VARIANT_VAL) > File "/tmp/ovirt-a0GNITSwX9/otopi-plugins/ovirt-host-deploy/node/detect.py", line 69, in hasconf > io.StringIO('[default]\n' + f.read().decode('utf-8')) > AttributeError: 'str' object has no attribute 'decode' > 2018-05-03 21:35:56,915+0200 ERROR otopi.context context._executeMethod:152 Failed to execute stage 'Initializing': 'str' object has no attribute 'decode' There is definitely a bug (or at least weirdness) in host-deploy -- why use .decode() on object returned by codecs.open()? But also, should host-deploy be already python3 compatible and is this otopi behaviour expected? Tomas -- Tomáš Golembiovský <tgolembi(a)redhat.com>

6 12

oVirt RPC messages
by Anastasiya Ruzhanskaya 07 May '18

07 May '18

Hello! Do messages sent from ovirt-engine to ovirt-node in RPC format contain the session number or any user information?

2 3