April 2019 - Devel - oVirt List Archives

[VDSM] Started getting virNetTLSContextCheckCertTimes:154 : The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired
by Edward Haas 11 Jan '24

11 Jan '24

Hi, I have a VM which acts as an oVirt host with VDSM installed. I use it for testing without connecting it to Engine. Recently VDSM fails to come up and I see this error: Sep 26 17:58:18 localhost libvirtd: 2018-09-26 14:58:18.978+0000: 12176: error : virNetTLSContextCheckCertTimes:154 : The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired Any hint on how to generate or fetch a new certificate without the help of Engine? Thanks, Edy.

3 5

Error Java SDK Issue??
by Geschwentner, Patrick 02 Apr '21

02 Apr '21

Dear Ladies and Gentlemen! I am currently working with the java-sdk and I encountered a problem. If I would like to retrieve the disk details, I get the following error: Disk currDisk = ovirtConnection.followLink(diskAttachment.disk()); The Error is occurring in this line: [cid:image001.png@01D44537.AF127FD0] The getResponst looks quiet ok. (I inspected: [cid:image002.png@01D44537.AF127FD0] and it looks ok). Error: wrong number of arguments The code is quiet similar to what you published on github (https://github.com/oVirt/ovirt-engine-sdk-java/blob/master/sdk/src/test/jav… ). Can you confirm the defect? Best regards Patrick

6 11

OST's basic suite UI sanity tests optimization
by Marcin Sobczyk 07 Aug '19

07 Aug '19

Hi, _TL; DR_ Let's cut the running time of '008_basic_ui_sanity.py' by more than 3 minutes by sacrificing Firefox and Chrome screenshots in favor of Chromium. During the OST hackathon in Brno this year, I saw an opportunity to optimize basic UI sanity tests from basic suite. The way we currently run them, is by setting up a Selenium grid using 3 docker containers, with a dedicated network... that's insanity! (pun intended). Let's a look at the running time of '008_basic_ui_sanity.py' scenario (https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test…) 01:31:50 @ Run test: 008_basic_ui_sanity.py: 01:31:50 nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] 01:31:50 # init: 01:31:50 # init: Success (in 0:00:00) 01:31:50 # start_grid: 01:34:05 # start_grid: Success (in 0:02:15) 01:34:05 # initialize_chrome: 01:34:18 # initialize_chrome: Success (in 0:00:13) 01:34:18 # login: 01:34:27 # login: Success (in 0:00:08) 01:34:27 # left_nav: 01:34:45 # left_nav: Success (in 0:00:18) 01:34:45 # close_driver: 01:34:46 # close_driver: Success (in 0:00:00) 01:34:46 # initialize_firefox: 01:35:02 # initialize_firefox: Success (in 0:00:16) 01:35:02 # login: 01:35:11 # login: Success (in 0:00:08) 01:35:11 # left_nav: 01:35:29 # left_nav: Success (in 0:00:18) 01:35:29 # cleanup: 01:35:36 # cleanup: Success (in 0:00:06) 01:35:36 # Results located at /dev/shm/ost/deployment-basic-suite-master/008_basic_ui_sanity.py.junit.xml 01:35:36 @ Run test: 008_basic_ui_sanity.py: Success (in 0:03:45) Starting the Selenium grid takes 2:15 out of 3:35 of total running time! I've investigated a lot of approaches and came up with something like this: * install 'chromium-headless' package on engine VM * download 'chromedriver' and 'selenium hub' jar and deploy them in '/var/opt/' on engine's VM * run 'selenium.jar' on engine VM from '008_basic_ui_sanity.py' by using Lago's ssh * connect to the Selenium instance running on the engine in '008_basic_ui_sanity.py' * make screenshots This series of patches represent the changes: https://gerrit.ovirt.org/#/q/topic:selenium-on-engine+(status:open+OR+statu…. This is the new running time (https://jenkins.ovirt.org/view/oVirt system tests/job/ovirt-system-tests_manual/4195/): 20:13:26 @ Run test: 008_basic_ui_sanity.py: 20:13:26 nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] 20:13:26 # init: 20:13:26 # init: Success (in 0:00:00) 20:13:26 # make_screenshots: 20:13:27 * Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fdb6004f8d0>: Failed to establish a new connection: [Errno 111] Connection refused',)': /wd/hub 20:13:27 * Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fdb6004fa10>: Failed to establish a new connection: [Errno 111] Connection refused',)': /wd/hub 20:13:27 * Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fdb6004fb50>: Failed to establish a new connection: [Errno 111] Connection refused',)': /wd/hub 20:13:28 * Redirecting http://192.168.201.4:4444/wd/hub -> http://192.168.201.4:4444/wd/hub/static/resource/hub.html 20:14:02 # make_screenshots: Success (in 0:00:35) 20:14:02 # Results located at /dev/shm/ost/deployment-basic-suite-master/008_basic_ui_sanity.py.junit.xml 20:14:02 @ Run test: 008_basic_ui_sanity.py: Success (in 0:00:35) (The 'NewConnectionErrors' is waiting for Selenium hub to be up and running, I can silence these later). And the screenshots are here: https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… _The pros:_ * we cut the running time by more than 3 minutes _The cons:_ * we don't get Firefox or Chrome screenshots - we get Chromium screenshots (although AFAIK, QE has much more Selenium tests which cover both Firefox and Chrome) * we polute the engine VM with 'chromium-headless' package and deps (in total: 'chromium-headless', 'chromium-common', 'flac-libs' and 'minizip'), although we can remove these after the tests _Some design choices explained:_ Q: Why engine VM? A: Because the engine VM already has 'X11' libs. We could install 'chromium-headless' (and even other browsers) on our Jenkins executors, but that would mess them up a lot. Q: Why Chromium? A: Because it has a separate 'headless' package. Q: Why not use 'chromedriver' RPM in favor of https://chromedriver.storage.googleapis.com Chromedriver builds? A: Because the RPM version pulls a lot of extra dependencies even on the engine VM ('gtk3', 'cairo' etc.). Builds from the URL are the offical Google Chromedriver builds, they contain a single binary, and they work for us. _What still needs to be polished with the patches:_ * Currently 'setup_engine_selenium.sh' script downloads each time 'selenium.jar' and 'chromedriver.zip' (even with these downloads we get much faster set-up times) - we should bake these into the engine VM image template. * 'selenium_hub_running' function in 'selenium_on_engine.py' is hackish - an ability to run an ssh command with a context manager (and auto-terminate on it exits) should be part of Lago. Can be refactored. Questions, comments, reviews are welcome. Regards, Marcin

7 10

ovirt-system-tests_compat-4.2-suite-master failing for 3 weeks?
by Doron Fediuck 17 May '19

17 May '19

https://jenkins.ovirt.org/job/ovirt-system-tests_compat-4.2-suite-master/55… The current failure is on adding a storage domain. Did anyone review it?

7 10

Testing oVirt with Gluster 6
by Simone Tiraboschi 13 May '19

13 May '19

Hi, according to https://bugzilla.redhat.com/show_bug.cgi?id=1673058 the network throughput usage increases by a x5 upgrading from Gluster 3.12 to Gluster 5.y. This seems definitively problematic on our hyper-converged environments: I read more than one report where, over 1 Gbps network, sanlock could not be refreshed quickly enough and so killed the engine VM if not rebooted the host due to the watchdog. This is probably due to the fact that, according to that bug, the network got completely saturated. Faster networks seems still fine. https://bugzilla.redhat.com/show_bug.cgi?id=1673058 is probably going to be solved for Gluster 5.6. On the other side we have https://bugzilla.redhat.com/1693998 <https://bugzilla.redhat.com/show_bug.cgi?id=1693998> about rebasing over Gluster 6 which seems not affected by that issue. Do you have concrete plans about testing oVirt with Gluster 6? thanks, Simone

5 7

Fedora 29 support?
by Nir Soffer 08 May '19

08 May '19

Fedora 28 will be EOL in few month, and at this point people are migration to Fedora 29. I tried yesterday to build engine development setup on Fedora 29 VM, and found that it does not work: - some packages are missing on engine side - after hacking the ovirt.repo files, pointing to "28" instead of "$releasever", I got the packages... - but then adding a host fail with "Python is missing" on the host, which is working Fedora 28 host used with engine before. What are our plans for supporting Fedora 29 on engine and host? I hope that the work we did for Fedora 28 will make it easier to port to Fedora 29. Nir

3 5

Fwd: Fedora 30 officially released!
by Sandro Bonazzola 30 Apr '19

30 Apr '19

FYI ---------- Forwarded message --------- Da: Matthew Miller <mattdm(a)fedoraproject.org> Date: mar 30 apr 2019 alle ore 16:02 Subject: Fedora 30 officially released! To: <announce(a)lists.fedoraproject.org> Cc: <devel-announce(a)lists.fedoraproject.org> It's been six months, and like clockwork, we release Fedora 30 today! Thank you to the thousands of people who worked to bring this release together. Fedora doesn't happen by magic: it happens because of you! Read the official announcement at: * https://fedoramagazine.org/announcing-fedora-30/ or just go ahead and grab it from: * https://getfedora.org/ -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr… -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0

Some feedback of an upgrade from 4.2 to 4.3 (EPYC Cluster)
by Tobias Scheinert 30 Apr '19

30 Apr '19

Hi, 1) Thank you all for the official support of the AMD EPYC processors in version 4.3! :-) 2) During the upgrade process I removed the old guest ISO file and replaced it with the new one (different filename of course). As I moved a virtual machine with the old ISO file mounted, the vm crashed. "Migration failed: Lost connection with qemu process (VM: <vmname>, Source: <ovirt-node-host>)." Yes I know this is not real bug (dumb user), but maybe it is good preventing the users for doing something stupid ;-) 3) The log contains following messages after upgrading the node: "VDSM <ovirt-node-host> command Get Host Statistics failed: Internal JSON-RPC error: {'reason': '[Errno 19] genev_sys_6081 is not present in the system'}" This stops after some time ~20-30 minutes, but comes back after a restart of a node. And disappears again after some time. At the moment we have no problems and not taking this as a real issue. 4) If we are running Windows 10 guests newer than build version 1709, the vm crashes on our EPYC cluster, on the SandyBridge cluster the issue doesn't exists. The reason is the wrong CPU model of QEMU, see: <https://bugzilla.redhat.com/show_bug.cgi?id=1593190> We fixed this problem with a line in "/etc/modprobe.d/kvm.conf" "options kvm ignore_msrs=1". Thank you all for this great piece of software :-) Regard Tobias

3 2

HA VM not work when VM OS cannot run normally
by du_hongyu＠yeah.net 30 Apr '19

30 Apr '19

HI， I create a HA VM in ovirt follaw this article https://ovirt.org/develop/ha-vms.html#highly-available-vms-and-io-errors when my vm‘s OS can not run, but ovirt consider this vm is up, so is this a bug for HA VM? can you give me some advise? Regards Hongyu Du

2 4

repo, el7: Provide nmstate through copr for VDSM
by Sandro Bonazzola 30 Apr '19

30 Apr '19

Hi, Is https://gerrit.ovirt.org/#/c/96856/ still relevant? I see nmstate-0.0.5 is in EPEL testing and shipped within Fedora while the copr repo has 0.0.4. Can I abandon the patch? -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

2 2

Nominating Miguel Barosso as ovirt-provider-ovn maintainer
by Marcin Mirecki 29 Apr '19

29 Apr '19

I would like to propose Miguel Barosso as a maintainer for ovirt-provider-ovn. Miguel is now working on the project for almost a year, and for the last few month is practically the only active contributor to the project. He has successfully implemented new features right up from the design stage, added a new integration test framework, fixed an endless amount of bugs and contributed over 200 patches to the project. Currently the only maintainer (me) is no longer actively working on the project, which is a cause of a review bottleneck. Thanks, Marcin

5 4

[ OST Failure Report ] [ oVirt 4.3 (vdsm) ] [ 22-03-2019 ] [ 002_bootstrap.add_master_storage_domain ]
by Dafna Ron 29 Apr '19

29 Apr '19

Hi, We are failing branch 4.3 for test: 002_bootstrap.add_master_storage_domain It seems that in one of the hosts, the vdsm is not starting there is nothing in vdsm.log or in supervdsm.log CQ identified this patch as the suspected root cause: https://gerrit.ovirt.org/#/c/98748/ - vdsm: client: Add support for flow id Milan, Marcin, can you please have a look? full logs: http://jenkins.ovirt.org/job/ovirt-4.3_change-queue-tester/326/artifact/bas… the only error I can see is about host not being up (makes sense as vdsm is not running) Stacktrace File "/usr/lib64/python2.7/unittest/case.py", line 369, in run testMethod() File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 142, in wrapped_test test() File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 60, in wrapper return func(get_test_prefix(), *args, **kwargs) File "/home/jenkins/workspace/ovirt-4.3_change-queue-tester/ovirt-system-tests/basic-suite-4.3/test-scenarios/002_bootstrap.py", line 417, in add_master_storage_domain add_iscsi_storage_domain(prefix) File "/home/jenkins/workspace/ovirt-4.3_change-queue-tester/ovirt-system-tests/basic-suite-4.3/test-scenarios/002_bootstrap.py", line 561, in add_iscsi_storage_domain host=_random_host_from_dc(api, DC_NAME), File "/home/jenkins/workspace/ovirt-4.3_change-queue-tester/ovirt-system-tests/basic-suite-4.3/test-scenarios/002_bootstrap.py", line 122, in _random_host_from_dc return _hosts_in_dc(api, dc_name, True) File "/home/jenkins/workspace/ovirt-4.3_change-queue-tester/ovirt-system-tests/basic-suite-4.3/test-scenarios/002_bootstrap.py", line 119, in _hosts_in_dc raise RuntimeError('Could not find hosts that are up in DC %s' % dc_name) 'Could not find hosts that are up in DC test-dc\n-------------------- >> begin captured logging << --------------------\nlago.ssh: DEBUG: start task:937bdea7-a2a3-47ad-9383-36647ea37ddf:Get ssh client for lago-basic-suite-4-3-engine:\nlago.ssh: DEBUG: end task:937bdea7-a2a3-47ad-9383-36647ea37ddf:Get ssh client for lago-basic-suite-4-3-engine:\nlago.ssh: DEBUG: Running c07b5ee2 on lago-basic-suite-4-3-engine: cat /root/multipath.txt\nlago.ssh: DEBUG: Command c07b5ee2 on lago-basic-suite-4-3-engine returned with 0\nlago.ssh: DEBUG: Command c07b5ee2 on lago-basic-suite-4-3-engine output:\n 3600140516f88cafa71243648ea218995\n360014053e28f60001764fed9978ec4b3\n360014059edc777770114a6484891dcf1\n36001405d93d8585a50d43a4ad0bd8d19\n36001405e31361631de14bcf87d43e55a\n\n-----------

8 31

oVirt Node build failure on 4.2 snapshot
by Sandro Bonazzola 28 Apr '19

28 Apr '19

https://jenkins.ovirt.org/job/ovirt-node-ng_4.2_build-artifacts-el7-x86_64/… Not sure what happened but yesterday ovirt Node 4.2 jenkins job started failing with: 06:28:14,517 INFO program:Error: Package: vdsm-client-4.20.47-2.git31d3591.el7.noarch (ovirt-4.2-snapshot) 06:28:14,518 INFO program:Requires: vdsm-api = 4.20.47-2.git31d3591.el7 06:28:14,518 INFO program:Available: vdsm-api-4.20.23-1.el7.noarch (ovirt-4.2-centos-ovirt42) 06:28:14,519 INFO program:vdsm-api = 4.20.23-1.el7 06:28:14,520 INFO program:Available: vdsm-api-4.20.39.1-1.el7.noarch (ovirt-4.2-centos-ovirt42) 06:28:14,521 INFO program:vdsm-api = 4.20.39.1-1.el7 06:28:14,522 INFO program:Error: Package: vdsm-jsonrpc-4.20.47-2.git31d3591.el7.noarch (ovirt-4.2-snapshot) 06:28:14,522 INFO program:Requires: vdsm-api = 4.20.47-2.git31d3591.el7 06:28:14,523 INFO program:Available: vdsm-api-4.20.23-1.el7.noarch (ovirt-4.2-centos-ovirt42) 06:28:14,524 INFO program:vdsm-api = 4.20.23-1.el7 06:28:14,525 INFO program:Available: vdsm-api-4.20.39.1-1.el7.noarch (ovirt-4.2-centos-ovirt42) 06:28:14,526 INFO program:vdsm-api = 4.20.39.1-1.el7 06:28:14,527 INFO program:Error: Package: vdsm-python-4.20.47-2.git31d3591.el7.noarch (ovirt-4.2-snapshot) 06:28:14,528 INFO program:Requires: vdsm-api = 4.20.47-2.git31d3591.el7 06:28:14,528 INFO program:Available: vdsm-api-4.20.23-1.el7.noarch (ovirt-4.2-centos-ovirt42) 06:28:14,529 INFO program:vdsm-api = 4.20.23-1.el7 06:28:14,530 INFO program:Available: vdsm-api-4.20.39.1-1.el7.noarch (ovirt-4.2-centos-ovirt42) 06:28:14,531 INFO program:vdsm-api = 4.20.39.1-1.el7 Looking at vdsm.spec I see: grep "\-api" vdsm.spec.in: Requires: %{name}-api = %{version}-%{release} Requires: %{name}-api = %{version}-%{release} Obsoletes: %{name}-api < 4.16 Requires: %{name}-api = %{version}-%{release} Requires: glusterfs-api >= %{gluster_version} Looking at the Obsoletes: %package jsonrpc Summary: VDSM API Server BuildArch: noarch Requires: %{name}-python = %{version}-%{release} Requires: %{name}-api = %{version}-%{release} Requires: %{name}-yajsonrpc = %{version}-%{release} Obsoletes: %{name}-api < 4.16 There's an Obsoletes without a Provides while there are still around lines with: Requires: %{name}-api = %{version}-%{release} so I don't know how it could have worked till now. -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

3 2

ovirt-engine has been tagged (ovirt-engine-4.3.3.6)
by Tal Nisan 24 Apr '19

24 Apr '19

1 0

ovirt-vmconsole CI check-patch
by Sandro Bonazzola 19 Apr '19

19 Apr '19

Hi, looks like ovirt-vmconsole is missing CI check-patch stage. Is there any reason for not running at least an rpm build in check-patch? I see the project has unit testing, why not run them on check-patch? Thanks, -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

2 2

Re: Is only master branch of ovirt-engine analyzed on coverity scan?
by Nasif Imtiaz 18 Apr '19

18 Apr '19

Hi Martin, Thanks for answering my questions. I am a PhD student at North Carolina State University. As a part of our research project, we are looking at how developers respond to alerts from static analysis tools (e.g. Coverity). If you can participate in a short survey <https://ncsu.qualtrics.com/jfe/form/SV_dakHeRNGBoWq9r7> answering how your project team monitors Coverity reports, that will help us greatly in our research. Thanks, Nasif

1 0

sanlock 3.7.1-2 for Fedora available in updates-testing
by Nir Soffer 16 Apr '19

16 Apr '19

This version refines the new 4k constants. If you use Fedora host, please test and submit feedback. To update sanlock: sudo dnf update --enablerepo=updates-testing sanlock python2-sanlock Submit feedback here: f28: https://bodhi.fedoraproject.org/updates/FEDORA-2019-3294cacaa5 f29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-3f694721ce f30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-fff6370c64 Thanks, Nir

1 0

ovirt-engine has been tagged (ovirt-engine-4.3.3.5)
by Tal Nisan 16 Apr '19

16 Apr '19

1 0

Re: Problem on host deployment from engine
by Nir Soffer 16 Apr '19

16 Apr '19

On Mon, Apr 15, 2019, 14:59 Amit Bawer <abawer(a)redhat.com> wrote: > Hello Didi & Sandro, > > I have encountered following issue when attempting to deploy a host from > the engine management. > > Engine: Fedora 28 > Host: CentOS 7.6.1810 > > engine.log error: > > 2019-04-14 14:08:35,578+03 INFO > [org.ovirt.engine.core.uutils.ssh.SSHDialog] > (EE-ManagedThreadFactory-engine-Thread-2) [628278a7] SSH execute ' > root(a)10.35.0.229' 'umask 0077; MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp > -d -t ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null > 2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; tar --warning=no-timestamp > -C "${MYTMP}" -x && "${MYTMP}"/ovirt-host-deploy > DIALOG/dialect=str:machine DIALOG/customization=bool:True' > 2019-04-14 14:08:35,670+03 ERROR > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > (VdsDeploy) [628278a7] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An > error has occurred during installation of Host host1: Python is required > but missing. > 2019-04-14 14:08:35,688+03 ERROR > [org.ovirt.engine.core.uutils.ssh.SSHDialog] > (EE-ManagedThreadFactory-engine-Thread-2) [628278a7] SSH error running > command root(a)10.35.0.229:'umask 0077; MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" > mktemp -d -t ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > > /dev/null 2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; tar > --warning=no-timestamp -C "${MYTMP}" -x && "${MYTMP}"/ovirt-host-deploy > DIALOG/dialect=str:machine DIALOG/customization=bool:True': IOException: > Command returned failure code 1 during SSH session 'root(a)10.35.0.229' > > > I managed to resolve it manually by installing following rpms over the > host machine before reattempting to deploy again the host from the engine > management: > > python2-otopi > python2-ovirt-host-deploy > > I should mention that both engine and host were built from git master > branch and not installed using the release rpms themselves, however Nir can > also testify there is an issue when trying to deploy a host from Fedora > engines (29 in Nir's case and 28 in my case). > > Thanks, > Amit > Adding devel > >

3 2

ovirt-engine has been tagged (ovirt-engine-4.2.8.7)
by Tal Nisan 15 Apr '19

15 Apr '19

1 0

4.2 HC suite - missing sanlock-lib 3.7.1 dependency
by Sahina Bose 15 Apr '19

15 Apr '19

The 4.2 HC suite is failing on missing dependencies Error: Package: python2-sanlock-3.7.1-1.el7.x86_64 (alocalsync) Requires: sanlock-lib = 3.7.1-1.el7 Installing: sanlock-lib-3.6.0-1.el7.x86_64 (alocalsync) sanlock-lib = 3.6.0-1.el7 Any recent changes here? On Sat, Apr 13, 2019 at 7:10 AM <jenkins(a)jenkins.phx.ovirt.org> wrote: > > Project: http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-4.2/ > Build: http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-4.2/852/ > Build Number: 852 > Build Status: Still Failing > Triggered By: Started by timer > > ------------------------------------- > Changes Since Last Success: > ------------------------------------- > Changes for Build #850 > [Dominik Holler] network-suite-4.2: Skip test to for vnic profile live update > > > Changes for Build #851 > [Martin Perina] common: Really enable debug logging for engine > > [Simone Tiraboschi] Skip he-basic-role-remote-suite-4.2 > > [Daniel Belenky] mock_configs: update rawhide releasever > > [Daniel Belenky] stdci_slaves: add timeouts to loader node > > > Changes for Build #852 > [Ondra Machacek] ansible_suite: Update datacenter version > > > > > ----------------- > Failed Tests: > ----------------- > No tests ran.

3 5

Fails to enter Import screen using the current master branch
by Steven Rosenberg 14 Apr '19

14 Apr '19

We found an issue where entering the Import functionality within the VM screen fails on ovirt-engine with an error message of 500. The link for the screen shot is as follows: https://imgur.com/a/AadtU1u Please advise if others have seen this issue as well and if there is a fix. With Best Regards. Steven Rosenberg.

5 11

[ OST Failure Report ] [ oVirt 4.2 (vdsm-jsonrpc-java) ] [ 12-04-2019 ] [ 002_bootstrap.add_dc ]
by Dafna Ron 14 Apr '19

14 Apr '19

Hi, We had a failure on both basic and upgrade suites. The issue seems to be in initialize engine with the below error Root cause change: https://gerrit.ovirt.org/#/c/99278/ - Purge old events and EventPublisher should handle exceptions Logs can be found here: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/4217/artifact/ba… error: 2019-04-12 03:36:25,571-04 ERROR [org.ovirt.engine.core.bll.Backend] (ServerService Thread Pool -- 44) [] Error during initialization: org.jboss.weld.exceptions.WeldException: WELD-000049: Unable to invoke private void org.ovirt.engine.core.vdsbroker.monitoring.VmMigrationProgressMonitoring.subscribe() on org.ovirt.engine.core.vdsbroker.monitoring.VmMigrationProgressMonitoring@c22d2ea at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:85) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.postConstruct(DefaultLifecycleCallbackInvoker.java:66) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.injection.producer.BasicInjectionTarget.postConstruct(BasicInjectionTarget.java:122) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:162) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.contexts.AbstractContext.get(AbstractContext.java:96) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:140) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:700) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.bean.builtin.InstanceImpl.getBeanInstance(InstanceImpl.java:252) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:114) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.ovirt.engine.core.bll.ServiceLoader.load(ServiceLoader.java:34) [bll.jar:] at org.ovirt.engine.core.bll.Backend.initialize(Backend.java:312) [bll.jar:] at org.ovirt.engine.core.bll.Backend.create(Backend.java:195) [bll.jar:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_201] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_201] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_201] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_201] at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:96) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:78) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:125) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:111) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81) [weld-ejb-3.0.5.Final.jar:3.0.5.Final] at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:53) [wildfly-weld-14.0.1.Final.jar:14.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56) [wildfly-weld-14.0.1.Final.jar:14.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee.component.ComponentInstantiatorInterceptor.processInvocation(ComponentInstantiatorInterceptor.java:74) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.weld.interceptors.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:105) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:216) [wildfly-ejb3-14.0.1.Final.jar:14.0.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:418) [wildfly-ejb3-14.0.1.Final.jar:14.0.1.Final] at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:70) [wildfly-ejb3-14.0.1.Final.jar:14.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43) [wildfly-weld-14.0.1.Final.jar:14.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-14.0.1.Final.jar:14.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-14.0.1.Final.jar:14.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.singleton.StartupCountDownInterceptor.processInvocation(StartupCountDownInterceptor.java:25) [wildfly-ejb3-14.0.1.Final.jar:14.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134) at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88) at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:127) [wildfly-ejb3-14.0.1.Final.jar:14.0.1.Final] at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:141) [wildfly-ejb3-14.0.1.Final.jar:14.0.1.Final] at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_201] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_201] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_201] at org.jboss.threads.JBossThread.run(JBossThread.java:485) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_201] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_201] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_201] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_201] at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:83) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] ... 69 more Caused by: java.lang.NoSuchMethodError: org.ovirt.vdsm.jsonrpc.client.reactors.ReactorFactory.getWorker(I)Lorg/ovirt/vdsm/jsonrpc/client/internal/ResponseWorker; at org.ovirt.engine.core.vdsbroker.ResourceManager.subscribe(ResourceManager.java:458) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.ResourceManager$Proxy$_$$_WeldSubclass.subscribe$$super(Unknown Source) [vdsbroker.jar:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_201] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_201] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_201] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_201] at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:51) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:78) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.ovirt.engine.core.common.di.interceptor.LoggingInterceptor.apply(LoggingInterceptor.java:12) [common.jar:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_201] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_201] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_201] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_201] at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68) [weld-core-impl-3.0.5.Final.jar:3.0.5.Final] at org.ovirt.engine.core.vdsbroker.ResourceManager$Proxy$_$$_WeldSubclass.subscribe(Unknown Source) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.monitoring.VmMigrationProgressMonitoring.subscribe(VmMigrationProgressMonitoring.java:35) [vdsbroker.jar:] ... 74 more 2019-04-12 03:36:46,992-04 DEBUG [org.ovirt.engine.core.utils.servlet.LocaleFilter] (default task-1) [] Incoming locale 'en-US'. Filter determined locale to be 'en-US' 2019-04-12 03:36:47,025-04 DEBUG [org.ovirt.engine.core.utils.servlet.LocaleFilter] (default task-1) [] Incoming locale 'en-US'. Filter determined locale to be 'en-US' 2019-04-12 03:36:47,027-04 DEBUG [org.ovirt.engine.core.uutils.ssh.OpenSSHUtils] (default task-1) [] Exponent is 65537 (010001). 2019-04-12 03:36:47,027-04 DEBUG [org.ovirt.engine.core.uutils.ssh.OpenSSHUtils] (default task-1) [] Modulus is 23045455587502151351307881395746676489582617487444460434296505697360842634378900404903793405238811523302482543003054056200741987458008963931649820493880963560986441075262188689772713221069929429876133085702357731148902133770193496183003052020349333463043013537857088409307780071693644400706574082881179894409681722899845950989200033040393214136788457749540203592306287581368470141041245429472069137351244033201424938951360962572394606552585936959608039675862808386819256128109473508142431203907117802195732456069118309327167040542073925080491412451765973629566066094113148306929852301896069383522789589872834454425973 (010001).

1 1

vdsm has been tagged (v4.20.48)
by Milan Zamazal 11 Apr '19

11 Apr '19

1 0

GetVdsHooksByIdQuery comes back with NullPointerException
by Dafna Ron 11 Apr '19

11 Apr '19

Hi, This is a code issue 100%, I am not sure which team sends the query but this needs to be addressed. I think it would also help debug/fix the issue with the random failure of get_host_hooks which was already reported and communicated on in the list. Can someone from infra/network please look at the query and see what is the cause of the NPE? Thanks, Dafna

2 2

Method add_vm_from_snapshot works incorrectly
by Aliaksei Hrechushkin 11 Apr '19

11 Apr '19

Hello! I'm try to create vm from snapshot using ovirt-engine-sdk-ruby i have script like that ``` vm = OvirtSDK4::Vm.new({name:"bkp_hanami",cluster:{name:"cluster-nb5"},disk_attachments:[{disk:{image_id:"24da6f72-f43f-4d8c-ad4f-cd3fb4f4ce35",storage_domain:{id:"07aaac7b-fddf-419b-bd40-766b58bf1588"}}},{disk:{image_id:"3db30d08-ff9c-4a6e-9252-dcb9fa01a2d5",storage_domain:{id:"07aaac7b-fddf-419b-bd40-766b58bf1588"}}}],snapshot:{id:"059a03b6-043a-46c8-a6af-07131a71df2a"}}) vms = connection.system_service.vms_service vms.add_from_snapshot(vm) ``` But as result i'm get ``` OvirtSDK4::Error: Fault reason is "Incomplete parameters". Fault detail is "Vm [template.id|name] required for add". HTTP response code is 400. ``` Ok, i'm added template id into hash and as result i'm getted xml D, [2019-04-11T09:53:38.773430 #66286] DEBUG -- : <vm> D, [2019-04-11T09:53:38.773511 #66286] DEBUG -- : <name>bkp_hanami</name> D, [2019-04-11T09:53:38.773585 #66286] DEBUG -- : <cluster> D, [2019-04-11T09:53:38.773641 #66286] DEBUG -- : <name>cluster-nb5</name> D, [2019-04-11T09:53:38.773735 #66286] DEBUG -- : </cluster> D, [2019-04-11T09:53:38.773823 #66286] DEBUG -- : <disk_attachments> D, [2019-04-11T09:53:38.773872 #66286] DEBUG -- : <disk_attachment> D, [2019-04-11T09:53:38.773966 #66286] DEBUG -- : <disk> D, [2019-04-11T09:53:38.774028 #66286] DEBUG -- : <image_id>24da6f72-f43f-4d8c-ad4f-cd3fb4f4ce35</image_id> D, [2019-04-11T09:53:38.774093 #66286] DEBUG -- : <storage_domain id="07aaac7b-fddf-419b-bd40-766b58bf1588"/> D, [2019-04-11T09:53:38.774161 #66286] DEBUG -- : </disk> D, [2019-04-11T09:53:38.774243 #66286] DEBUG -- : </disk_attachment> D, [2019-04-11T09:53:38.774310 #66286] DEBUG -- : <disk_attachment> D, [2019-04-11T09:53:38.774393 #66286] DEBUG -- : <disk> D, [2019-04-11T09:53:38.774463 #66286] DEBUG -- : <image_id>3db30d08-ff9c-4a6e-9252-dcb9fa01a2d5</image_id> D, [2019-04-11T09:53:38.774531 #66286] DEBUG -- : <storage_domain id="07aaac7b-fddf-419b-bd40-766b58bf1588"/> D, [2019-04-11T09:53:38.774593 #66286] DEBUG -- : </disk> D, [2019-04-11T09:53:38.774710 #66286] DEBUG -- : </disk_attachment> D, [2019-04-11T09:53:38.774807 #66286] DEBUG -- : </disk_attachments> D, [2019-04-11T09:53:38.774869 #66286] DEBUG -- : <template id="5f3ff226-908c-478a-a2e0-d49f4204c99b"/> D, [2019-04-11T09:53:38.774957 #66286] DEBUG -- : </vm> What parameters i'm should pass in function vms_services.add_vm_from_snapshot() to really creating vm from snapshot p.s. when i'm use restclient all works great. (Ovirt 4.2.8, gem ovirt-engine-sdk-4.2.5)

1 1

ovirt-engine has been tagged (ovirt-engine-4.3.3.4)
by Tal Nisan 11 Apr '19

11 Apr '19

1 0

Sanlock 3.7.1 for Fedora is available for testing
by Nir Soffer 11 Apr '19

11 Apr '19

sanlock 3.7.1 for Fedora 28, 29, and 30 is available now in the updates-testing repo. The main change in this version is support for configurable sector size and alignment, needed for 4k support in 4.3.z. If you have oVirt Fedora hosts please test this version and submit feedback: f28: https://bodhi.fedoraproject.org/updates/FEDORA-2019-2f7165dc3f f29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-2f7165dc3f f30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-0349c17155 To update use: sudo dnf update --enablerepo=updates-testing sanlock python2-sanlock Sandro: we discussed building sanlock for CentOS once we release it for Fedora, so we can start using it for OST now. Eyal, what do we need to start using this sanlock version in the CI and OST? Nir

3 2

[Ovirt] [CQ weekly status] [05-04-2019]
by Dafna Ron 11 Apr '19

11 Apr '19

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-4.2*: GREEN (#1) Last CQ job failure on 4.2 was 05-04-2019 on project ovirt-provider-ovn due to a code regression which was caused by [1] The issue has been found and a patch created [2] but due to the hotplug_cpu failure, it took a long time to verify the fix before merge. [1] https://gerrit.ovirt.org/#/c/98723/ - Stateless dhcpv6 does not support fixed IPs [2] https://gerrit.ovirt.org/#/c/99193/ - Fix bug when fixed IPs are not provisioned *CQ-4.3*: RED (#3) We have been having constant failures on tests: hotplug_cpu add_master_storage_domain The failures on these two are very frequent and I need to re-trigger tests on multiple failures daily. There is a mail thread on this and several people have joined in to help debug the issue but I think that this issue needs more help from some of the other teams as its been going on for the last two weeks at least. This is also disrupting fixing actual regressions as the testing keep failing on these two unrelated issues. *CQ-Master:* RED (#3) Master and 4.3 have the same issues. Current running jobs for 4.2 [1], 4.3 [2] and master [3] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.2_change-qu… [2] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.3_change-q… [3] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change… Happy week! Dafna ------------------------------------------------------------------------------------------------------------------- COLOUR MAP Green = job has been passing successfully ** green for more than 3 days may suggest we need a review of our test coverage 1. 1-3 days GREEN (#1) 2. 4-7 days GREEN (#2) 3. Over 7 days GREEN (#3) Yellow = intermittent failures for different projects but no lasting or current regressions ** intermittent would be a healthy project as we expect a number of failures during the week ** I will not report any of the solved failures or regressions. 1. Solved job failures YELLOW (#1) 2. Solved regressions YELLOW (#2) Red = job has been failing ** Active Failures. The colour will change based on the amount of time the project/s has been broken. Only active regressions would be reported. 1. 1-3 days RED (#1) 2. 4-7 days RED (#2) 3. Over 7 days RED (#3)

2 1

ovirt-engine has been tagged (ovirt-engine-4.2.8.6)
by Tal Nisan 10 Apr '19

10 Apr '19

1 0

Python 3 vdsm RPM packages
by Marcin Sobczyk 10 Apr '19

10 Apr '19

Hi, On yesterday's vdsm weekly call, we were discussing the need of making Python 3 vdsm RPM packages. Some facts: - it doesn't make a lot sense to spend much time on trying to package everything - it's completely impossible i.e. to run vdsm without having 'sanlock' module - our current vdsm.spec file is crap Two non-exclusive propositions were raised: - let's try to make a quick-and-dirty patch, that will completely overwrite the existing 'vdsm.spec' (effectively making it Python 3-only) for testing purposes, and maintain it for a while - in the meantime, let's write a completely new, clean and beautiful spec file in an package-by-package, incremental manner, (also Python 3-only) that would eventually substitute the original one The quick-and-dirty spec file would be completely unsupported by CI. The new one would get a proper CI sub-stage in 'build-artifacts' stage. The steps needed to be done are: - prepare autotools/Makefiles to differentiate Python 2/Python 3 RPM builds - prepare the new spec file (for now including only 'vdsm-common' package) - split 'build-artifacts' stage into 'build-py27' and 'build-py36' sub-stages (the latter currently running on fc28 only) The only package we can start with, when making the new spec file, is 'vdsm-common', as it doesn't depend on anything else (or at least I hope so...). There were also propositions about how to change the new spec file in regard to the old one (like making 'vdsm' package a meta-package). This is a good time for these propositions to be raised, reviewed and documented (something like this maybe? https://docs.google.com/document/d/13EXN1Iwq-OPoc2A5Y3PJBpOiNC10ugx6eCE72K6…) so we can align the new spec file as we build it. I can lay the groundwork by doing the autotools/Makefiles and 'build-artifacts' splitting. Gal Zaidman agreed on starting to work on the new spec file. Milan mentioned, that he had something like the quick-and-dirty patch, maybe he can share it with us. Questions, comments are welcome. Regards, Marcin

5 12

Re: VDSM and safelease
by Michal Skrivanek 10 Apr '19

10 Apr '19

On 5 Apr 2019, at 09:31, Martin Tessun <mtessun(a)redhat.com> wrote: Hi Sandro, Michal, On 4/5/19 9:01 AM, Sandro Bonazzola wrote: Il giorno gio 4 apr 2019 alle ore 19:15 Michal Skrivanek < michal.skrivanek(a)redhat.com> ha scritto: > > > On 3 Apr 2019, at 13:24, Martin Perina <mperina(a)redhat.com> wrote: > > > > On Wed, Apr 3, 2019 at 10:22 AM Martin Tessun <mtessun(a)redhat.com> wrote: > >> On 4/3/19 8:25 AM, Sandro Bonazzola wrote: >> >> So, according to the thread we have a few action items: >> - Decide if we'll drop export domain and iso domain in 4.4 >> >> > Just please don't forget that 4.4 engine will need to support 4.2, 4.3 and > 4.4 hosts and we will need to allow migrating VMs from 4.2/4.3 hosts (EL7) > to 4.4 hosts (EL8), so we need to be careful about implications of removing > ISO and export data domains > > > In general we can’t remove anything while the corresponding cluster level > is still supported. So feel free to drop anything we used in <4.2, but > think twice and (run that through virt team at least) before you remove > anything used in 4.2+ > Ok, so: do we need to take safelease with us in 4.4? If the answer is yes, I need to request to find a maintainer for it since we'll need to package it for RHEL 8 / CentOS 8. This is currently blocking pre-integration testing with RHEL 8 Beta so it needs to be addressed quickly in order to be able to proceed. First question: Up to which clusterlevel is safelease needed? Is it needed in 4.2 cluster level? Also 4.3 If so: safelease is probably only required on RHEL 7 hypervisors then. In that case we don't need it for RHEL 8 Hypervisors. If we won’t have it on RHEL 8/4.4 then you are effectively cutting off <4.4 support in 4.4 vdsm. Which also means no live migration between 4.3 compat level which means no way to upgrade to 4.4 with running VMs. I do not think that’s acceptable So in case we remove safelease from RHV 4.4/RHEL 8 based hypervisors we should be fine. In case safelease is needed for the engine, we need to think if we want to move the engine to RHEL 8 in that case. Cheers, Martin > >> If we do so, we still need a way to clean these old domains up, aka >> moving the ISOs to a Data Domain or "migrating" an existing ISO domain into >> a data Domain. >> Export Domain is probably easier, as the OVAs can simply be copied to a >> central location. Maybe having an export domain available as a second way >> to upload VMs (e.g. for bulk-imports) still makes sense. Esp. as I believe >> v2v is relying on export domains today. >> >> So while I am in favor of getting rid of unneeded code, we need to think >> about the benefits they both have and how to get them implemented in case >> we agree on removing the old domains. >> >> So what are the benefits of the ISO domain: >> >> - Easy to add new ISOs (just copy them to the NFS location >> - simple way of sharing between DCs/RHV-Ms >> - Having a central place for the ISOs >> >> The 3rd item can be achieved by admins simply using one Storage Domain >> just for ISOs. >> The 2nd would probably require some sort of read-only SDs or a way to >> have one SD shared between DCs with just one DC having write-access. >> The 1st one is probably hardest, as there is no easy way of adding data >> to the Storage Domain without tooling. Maybe there are also other ways of >> achieving this, the above are just my ideas. >> >> >> Next - what are the benefits of Export Domain: >> >> - Unattended Import >> - Bulk Im- and Export >> - Central location >> - Easily sharable between DCs/RHV-Ms >> >> The 4th one is already achieved as we have a common Import/Export tool, >> so the OVAs can be easily shared and used by different DCs/RHV-Ms >> The 3rd one is something that could be easily achieved administrately. >> The 2nd one is already more complicated, but can probably be solved with >> Ansible (as the 1st one probably as well). >> >> >> So from my PoV it is easiest to remove the Export Domain while still >> having all needed features available. The ISO domain seems a bit harder to >> me. >> Please think about how to solve this, before we decide on removing both >> of them. >> >> >> Cheers, >> Martin >> >> >> - Move requirements from safelease to vdsm for numactl, dmidecode and >> virt-v2v if not already done >> - Elect a maintainer for safelease for 4.3 scope >> - Deprecate safelease in 4.3 and remove it on master if we agree on >> removing iso and export domain in 4.4 >> >> Il giorno mar 2 apr 2019 alle ore 18:14 Nir Soffer <nsoffer(a)redhat.com> >> ha scritto: >> >>> On Tue, Apr 2, 2019 at 6:40 PM Dan Kenigsberg <danken(a)redhat.com> wrote: >>> >>>> >>>> >>>> On Tue, Apr 2, 2019 at 6:07 PM Nir Soffer <nsoffer(a)redhat.com> wrote: >>>> >>>>> On Tue, Apr 2, 2019 at 5:00 PM Sandro Bonazzola <sbonazzo(a)redhat.com> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> I stumbled upon safelease package, introduced in oVirt 3.6. >>>>>> I realigned the spec file with Fedora Rawhide: >>>>>> https://gerrit.ovirt.org/#/c/99123/ >>>>>> and then I stopped working on it and decided to open a thread here. >>>>>> >>>>>> safelease package is required in vdsm. >>>>>> I searched for the home page for this package since it moved and >>>>>> found: https://ovirt.org/develop/developer-guide/vdsm/safelease.html >>>>>> This says that sanlock is meant to obsolete safelease. >>>>>> I'm assuming that safelease was used in 3.6 and replaced later by >>>>>> sanlock then kept for backward compatibility. >>>>>> In 4.3 we dropped support for 3.6 level clusters, is this package >>>>>> still needed? >>>>>> >>>>> >>>>> safelease is our clusterlock with V1 storage domains - export and iso >>>>> domains. >>>>> >>>>> https://github.com/oVirt/vdsm/blob/f433ed5aaf67729b787cf82ee21b0f17af968be4… >>>>> https://github.com/oVirt/vdsm/blob/master/lib/vdsm/storage/sd.py#L320 >>>>> >>>>> Once we remove these domains we can remove also safelease. >>>>> >>>>> If it's still needed, why is it requiring: >>>>>> # Numactl is not available on s390[x] and ARM >>>>>> %ifnarch s390 s390x %{arm} >>>>>> Requires: numactl >>>>>> %endif >>>>>> >>>>>> %ifarch x86_64 >>>>>> Requires: python2-dmidecode >>>>>> Requires: dmidecode >>>>>> Requires: virt-v2v >>>>>> %endif >>>>>> >>>>> >>>>> These are hacks Yaniv added so we can make vdsm noarch package. Since >>>>> then we reverted >>>>> back to vdsm arch specific package but the bad requirements remained >>>>> in safelease. >>>>> >>>>> We can safely remove the requirements from safelease if vdsm requires >>>>> these packages, but >>>>> I'm not sure who has time to work on safelease. >>>>> >>>>> I think it is time to remove export and iso domain in 4.4. >>>>> >>>> >>>> Would it be possible? >>>> If an ovirt-4.3 storage pool has an ISO domain, and we add an ovirt-4.4 >>>> host to it, we would like it to be able to become SPM. >>>> >>> >>> In rhel 8.1, vdsm 4.4, I don't want to support export or iso domain >>> regardless of the >>> cluster version. >>> >>> We don't have the time to port all code in vdsm to python 3. If you want >>> python 3, you need >>> to remove some features. >>> >>> If you want to mix 4.4. host with 4.3, env, detach the iso domain and >>> export domain? >>> >>> Tal, what do you think? >>> >>>> >> >> -- >> >> SANDRO BONAZZOLA >> >> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV >> >> Red Hat EMEA <https://www.redhat.com/> >> >> sbonazzo(a)redhat.com >> <https://red.ht/sig> >> >> >> -- >> Martin Tessun >> Senior Technical Product Manager KVM, Red Hat GmbH (Munich Office) >> >> mobile +49.173.6595494 >> desk +49.89.205071-107 >> fax +49.89.205071-111 >> >> GPG Fingerprint: EDBB 7C6A B5FE 9199 B861 478D 3526 E46D 0D8B 44F0 >> >> Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, >> Commercial register: Amtsgericht Muenchen, HRB 153243, >> Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander >> >> _______________________________________________ >> Devel mailing list -- devel(a)ovirt.org >> To unsubscribe send an email to devel-leave(a)ovirt.org >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >> oVirt Code of Conduct: >> https://www.ovirt.org/community/about/community-guidelines/ >> List Archives: >> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/JZZEG5LQLLAGS… >> > > > -- > Martin Perina > Manager, Software Engineering > Red Hat Czech s.r.o. > > _______________________________________________ > Devel mailing list -- devel(a)ovirt.org > To unsubscribe send an email to devel-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/devel@ovirt.org/message/GRB2666BFX3OI… > > _______________________________________________ > Devel mailing list -- devel(a)ovirt.org > To unsubscribe send an email to devel-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/devel@ovirt.org/message/45RWPIMLH6MYV… > -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> -- Martin Tessun Senior Technical Product Manager KVM, Red Hat GmbH (Munich Office) mobile +49.173.6595494 desk +49.89.205071-107 fax +49.89.205071-111 GPG Fingerprint: EDBB 7C6A B5FE 9199 B861 478D 3526 E46D 0D8B 44F0 Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander

6 9

Merging change into OST network-suite
by Dominik Holler 09 Apr '19

09 Apr '19

Hallo, currently OST network-suite-4.2 is broken by a test executed unintentional in network-suite-4.2. To unbreak, https://gerrit.ovirt.org/#/c/99289/ can be used. Because Edy is not available to merge, it would be helpful if someone else with merge power would merge the change/ Thanks Dominik

2 1

Network Labels and API Access (Error in documentation)
by jorr＠streamguys.com 08 Apr '19

08 Apr '19

The self-hosted documentation for network labels appears to be inaccurate. https://{{ MY_DOMAIN }}/ovirt-engine/apidoc/#/services/network_labels/methods/add The documentation asks the user to post to the following URI: POST /ovirt-engine/api/networks/123/labels However that results in a 404. The following URL should be posted to instead for a successful response: POST /ovirt-engine/api/networks/123/networklabels I discovered the discrepancy when trying to curl loop automate adding networks to my cluster, and resulted in 404s. The 'links' section of the specific network label actually do contain the right URI to hit to get the proper label tagging: "link": [ { "href": "/ovirt-engine/api/networks/929fec34-7a34-4c1b-9451-e6abf6733ac6/networklabels", "rel": "networklabels" }, { "href": "/ovirt-engine/api/networks/929fec34-7a34-4c1b-9451-e6abf6733ac6/permissions", "rel": "permissions" }, { "href": "/ovirt-engine/api/networks/929fec34-7a34-4c1b-9451-e6abf6733ac6/vnicprofiles", "rel": "vnicprofiles" } ] The hosted documentation also has confusing information with networklabels being used in the results of some requests, but this section here also just says 'labels': https://ovirt.github.io/ovirt-engine-api-model/4.1/#services/network_labels…

2 2

ovirt-engine has been tagged (ovirt-engine-4.3.3.3)
by Tal Nisan 08 Apr '19

08 Apr '19

1 0

vdsm has been tagged (v4.30.13)
by Milan Zamazal 08 Apr '19

08 Apr '19

1 0

VDSM and safelease
by Sandro Bonazzola 05 Apr '19

05 Apr '19

Hi, I stumbled upon safelease package, introduced in oVirt 3.6. I realigned the spec file with Fedora Rawhide: https://gerrit.ovirt.org/#/c/99123/ and then I stopped working on it and decided to open a thread here. safelease package is required in vdsm. I searched for the home page for this package since it moved and found: https://ovirt.org/develop/developer-guide/vdsm/safelease.html This says that sanlock is meant to obsolete safelease. I'm assuming that safelease was used in 3.6 and replaced later by sanlock then kept for backward compatibility. In 4.3 we dropped support for 3.6 level clusters, is this package still needed? If it's still needed, why is it requiring: # Numactl is not available on s390[x] and ARM %ifnarch s390 s390x %{arm} Requires: numactl %endif %ifarch x86_64 Requires: python2-dmidecode Requires: dmidecode Requires: virt-v2v %endif while nothing of above packages seems to be used within the source code of this package? Currently listed maintainers for this package are: Saggi Mizrahi (doesn't seems to be in oVirt project anymore) Yaniv Bronhaim (doesn't seems to be in oVirt project anymore) Yoav Kleinberger (doesn't seems to be in oVirt project anymore) Any thought? -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

7 13

Suspend resume and DHCP
by Dominik Holler 04 Apr '19

04 Apr '19

Hello, would you help me to understand if the dhcp client in an oVirt guest should refresh his dhcp configuration after the guest is resumed? If this is the case, how this should be triggered? The reason why I ask is, that if a VM suspends on a first host, and resumes on a second one, libvirt's nwfilter losses the IP address of the guest, which means that the guest is not reachable until he refreshes dhcp config, if the clean-traffic filter with CTRL_IP_LEARNING=dhcp is used. This scenario might happen in OST basic-suite-master and basic-suite-4.3 in verify_suspend_resume_vm0. Thanks Dominik

4 4

ovirt-engine has been tagged (ovirt-engine-4.3.3.2)
by Tal Nisan 03 Apr '19

03 Apr '19

1 0

[ OST Failure Report ] [ oVirt master (ovirt-engine) ] [ 22-03-2019 ] [004_basic_sanity.hotplug_cpu ]
by Dafna Ron 02 Apr '19

02 Apr '19

Hi, We are failing ovirt-engine master on test 004_basic_sanity.hotplug_cpu looking at the logs, we can see that the for some reason, libvirt reports a vm as none responsive which fails the test. CQ first failure was for patch: https://gerrit.ovirt.org/#/c/98553/ - core: Add display="on" for mdevs, use nodisplay to override But I do not think this is the cause of failure. Adding Marcin, Milan and Dan as well as I think it may be netwrok related. You can see the libvirt log here: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13516/artifa… you can see the full logs here: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13516/artifac… Evgheni and I confirmed this is not an infra issue and the problem is ssh connection to the internal vm Thanks, Dafna error: 2019-03-22 15:08:22.658+0000: 22068: warning : qemuDomainObjTaint:7521 : Domain id=3 name='vm0' uuid=a9443d02-e054-40bb-8ea3-ae346e2d02a7 is tainted: hook-script 2019-03-22 15:08:22.693+0000: 22068: error : virProcessRunInMountNamespace:1159 : internal error: child reported: unable to set security context 'system_u:object_r:virt_content_t:s0' on '/rhev/data-center/mnt/blockSD/91d97292-9ac3-4d77-a152-c7ea3250b065/images/e60dae48-ecc7-4171-8bfe-42bfc2190ffd/40243c76-a384-4497-8a2d-792a5e10d510': No such file or directory 2019-03-22 15:08:28.168+0000: 22070: error : qemuDomainAgentAvailable:9133 : Guest agent is not responding: QEMU guest agent is not connected 2019-03-22 15:08:58.193+0000: 22070: error : qemuDomainAgentAvailable:9133 : Guest agent is not responding: QEMU guest agent is not connected 2019-03-22 15:13:58.179+0000: 22071: error : qemuDomainAgentAvailable:9133 : Guest agent is not responding: QEMU guest agent is not connected

8 17

oVirt Survey 2019 results
by Sandro Bonazzola 02 Apr '19

02 Apr '19

Thanks to the 143 participants to oVirt Survey 2019! The survey is now closed and results are publicly available at https://bit.ly/2JYlI7U We'll analyze collected data in order to improve oVirt thanks to your feedback. As a first step after reading the results I'd like to invite the 30 persons who replied they're willing to contribute code to send an email to devel(a)ovirt.org introducing themselves: we'll be more than happy to welcome them and helping them getting started. I would also like to invite the 17 people who replied they'd like to help organizing oVirt events in their area to either get in touch with me or introduce themselves to users(a)ovirt.org so we can discuss about events organization. Last but not least I'd like to invite the 38 people willing to contribute documentation and the one willing to contribute localization to introduce themselves to devel(a)ovirt.org. Thanks! -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0