August 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: Adding new Host to ovirt-engine
by Ahmad Khiet 14 Aug '23

14 Aug '23

Hi, Can't add new host to ovirt engine, because the following error: 2019-06-12 12:23:09,664 p=4134 u=engine | TASK [ovirt-host-deploy-facts : Set facts] ************************************* 2019-06-12 12:23:09,684 p=4134 u=engine | ok: [10.35.1.17] => { "ansible_facts": { "ansible_python_interpreter": "/usr/bin/python2", "host_deploy_vdsm_version": "4.40.0" }, "changed": false } 2019-06-12 12:23:09,697 p=4134 u=engine | TASK [ovirt-provider-ovn-driver : Install ovs] ********************************* 2019-06-12 12:23:09,726 p=4134 u=engine | fatal: [10.35.1.17]: FAILED! => {} MSG: The conditional check 'cluster_switch == "ovs" or (ovn_central is defined and ovn_central | ipaddr and ovn_engine_cluster_version is version_compare('4.2', '>='))' failed. The error was: The ipaddr filter requires python's netaddr be installed on the ansible controller The error appears to be in '/home/engine/apps/engine/share/ovirt-engine/playbooks/roles/ovirt-provider-ovn-driver/tasks/configure.yml': line 3, column 5, but may be elsewhere in the file depending on the exact syntax problem. The offending line appears to be: - block: - name: Install ovs ^ here 2019-06-12 12:23:09,728 p=4134 u=engine | PLAY RECAP ********************************************************************* 2019-06-12 12:23:09,728 p=4134 u=engine | 10.35.1.17 : ok=3 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 whats missing!? Thanks -- Ahmad Khiet Red Hat <https://www.redhat.com/> akhiet(a)redhat.com M: +972-54-6225629 <https://red.ht/sig>

7 10

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

Dropping local crypto settings throughout oVirt in favour of crypto policies
by Marcin Sobczyk 07 Nov '19

07 Nov '19

Hi, given that crypto policies appeared in RHEL8 I think it's a good time to discuss using them throughout oVirt. I prepared a document, that describes the current state of crypto settings in VDSM along with the benefits and potential issues that come with moving to crypto policies. If you have a moment, please go through the doc - any input and comments are welcome. https://docs.google.com/document/d/1K19jDOITEQenPDbbSft2ChgGrL_DgpcbQon_bWL… Regards, Marcin Sobczyk

2 2

unicode sandwich in otopi/engine-setup
by Yedidyah Bar David 24 Sep '19

24 Sep '19

Hi all, This is in a sense a continuation of the thread "Why filetransaction needs to encode the content to utf-8?", but I decided that a new thread is better. I started to systematically convert the code to use a unicode sandwich. I admit it was harder than I expected, and made me think somewhat differently about the move to python3, and about how reasonable (or not) it is to develop in the common subset of python2 and python3 vs ditching python2 and moving fully to python3. It seems like at least parts of our (integration team) code will still have to run in python2 also in oVirt 4.4, so I guess we'll not have much choice :-) Current patches are only for otopi and engine-setup, and are by no means thorough - I didn't check each and every open() call and similar ones. But it's enough for getting engine-setup finish successfully on both python2 and python3 (EL7 and Fedora 29), with some utf-8 inserted in relevant places of the input (for the plugins already handled). I didn't bother trying non-utf-8 encodings. Perhaps I should, but it's not completely clear to me what's the best approach [2]. Currently, you must have both otopi and engine updated to get things working. If there is demand, I might spend some time splitting/rebasing/etc to make it possible to update just one of them and only later the other, but not sure it's worth it. I don't mind splitting/squashing if it makes reviews simpler, but I think the patches are ok as-is. These are the bottom patches of each stack: otopi: https://gerrit.ovirt.org/102085 engine-setup: https://gerrit.ovirt.org/102934 [1] http://python-future.org/unicode_literals.html [2] https://stackoverflow.com/questions/4012571/python-which-encoding-is-used-f… Thanks and best regards, -- Didi

2 5

[VDSM] storage python 3 tests status
by Nir Soffer 10 Sep '19

10 Sep '19

Sharing progress on python 3 work. ## 2 weeks ago git checkout @{two.weeks.ago} tox -e storage-py37 ... 1448 passed, 103 skipped, 100 deselected, 322 xfailed, 236 warnings in 71.40 seconds ## Today git checkout tox -e storage-py37 ... 1643 passed, 103 skipped, 100 deselected, 105 xfailed, 82 xpassed, 107 warnings in 79.72 seconds Change: *passed: +195* *skips: 0* *xfail: -217* *xpass: +107* *warnings: -129* ## XPASS 107 xpass are most likely easy fix, just remove the xfail() mark from the test or parameter. Patches should not introduce new XPASS, you should remove all xfail() marks that a patch fixes. To test that your patch do not introduce new XPASS, add this option to tox.ini: [pytest] xfail_strict = True This converts XPASS to FAIL. These modules need to be fixed: $ egrep '^storage.+_test.py.+X' storage-py37.out storage/filevolume_test.py ...XXXxXXXXxXXX [ 19%] storage/formatconverter_test.py XXXXXxxss [ 20%] storage/merge_test.py XXXXXXxxxxXXxXxxxxxXxxxxxx [ 38%] storage/nbd_test.py ssssssssssssX. [ 49%] storage/sd_manifest_test.py XXXXXXXXXxxxxxxxxxxxxxxxxxxxxxxx............ [ 65%] storage/sdm_amend_volume_test.py xXxXxXxX [ 66%] storage/sdm_copy_data_test.py xXXxxxxXXXXXxxxXXXxxXXxxXXx [ 67%] storage/sdm_merge_test.py xxxxXXX [ 79%] storage/sdm_update_volume_test.py xXxXxxXXxxXXxXxXxXxX....... [ 81%] storage/testlib_test.py xXXXxxXXXXXXXXxxxxxxxxxxxxxXxXxXxX.......... [ 87%] storage/volume_metadata_test.py ..........................X............. [ 90%] ## xfail We must fix these xfail before we can run OST. If we start running OST we will waste days debugging OST. Debugging failing tests is 1000X times faster. $ egrep '^storage.+_test.py.+x' storage-py37.out storage/blocksd_test.py ........x..........sssssssssss............ [ 4%] storage/blockvolume_test.py ...........xxxxxxxxx [ 5%] storage/fileutil_test.py ..xx....ss............................ [ 19%] storage/filevolume_test.py ...XXXxXXXXxXXX [ 19%] storage/formatconverter_test.py XXXXXxxss [ 20%] storage/merge_test.py XXXXXXxxxxXXxXxxxxxXxxxxxx [ 38%] storage/sd_manifest_test.py XXXXXXXXXxxxxxxxxxxxxxxxxxxxxxxx............ [ 65%] storage/sdm_amend_volume_test.py xXxXxXxX [ 66%] storage/sdm_copy_data_test.py xXXxxxxXXXXXxxxXXXxxXXxxXXx [ 67%] storage/sdm_merge_test.py xxxxXXX [ 79%] storage/sdm_update_volume_test.py xXxXxxXXxxXXxXxXxXxX....... [ 81%] storage/testlib_test.py xXXXxxXXXXXXXXxxxxxxxxxxxxxXxXxXxX.......... [ 87%] ## Skips Skips should be used only when test cannot run on specific environment, but I think we have some wrong skips that should have been xfail. $ egrep '^storage.+_test.py.+s' storage-py37.out storage/backends_test.py ss [ 2%] storage/blockdev_test.py ssss....s [ 2%] storage/blocksd_test.py ........x..........sssssssssss............ [ 4%] storage/devicemapper_test.py s. [ 9%] storage/fileutil_test.py ..xx....ss............................ [ 19%] storage/formatconverter_test.py XXXXXxxss [ 20%] storage/loopback_test.py ssss [ 31%] storage/lvm_test.py ....................ssssssssssssssssssss [ 33%] storage/lvmfilter_test.py .....ss.......... [ 35%] storage/managedvolume_test.py ssssssssssssssssss.... [ 36%] storage/misc_test.py .................sssssssss...............ssss...... [ 41%] storage/mount_test.py .........ss........ssssss [ 47%] storage/nbd_test.py ssssssssssssX. [ 49%] storage/udev_multipath_test.py .......................s [ 88%] ## Warnings See "warnings summary" in pytest output. Looks less useful, report issues in packages we use instead of issues in our code. But this may be an issue using old versions of packages. See attached results created with: tox -e storage-py37 > storage-py37.out 2>&1 Nir

2 3

Ovirt Manager - FATAL: the database system is in recovery mode
by Sameer Sardar 10 Sep '19

10 Sep '19

PACKAGE_NAME="ovirt-engine" PACKAGE_VERSION="3.6.2.6" PACKAGE_DISPLAY_VERSION="3.6.2.6-1.el6" OPERATING SYSTEM="Centos 6.7" Its been running error-free for over 3 years now. Over the past few weeks, The Ovirt manager application has been frequently losing connection with its own database residing on the same server. It is throwing up errors saying: “Caused by org.postgresql.util.PSQLException: FATAL: the database system is in recovery mode”. The only means we have found to recover from this is to hard reboot the server, after which it works fine for a couple of days before throwing up these errors again. Here are some logs : Caused by: org.postgresql.util.PSQLException: FATAL: the database system is in recovery mode at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:293) at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:108) at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66) at org.postgresql.jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java:125) at org.postgresql.jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Connection.java:30) at org.postgresql.jdbc3g.AbstractJdbc3gConnection.<init>(AbstractJdbc3gConnection.java:22) at org.postgresql.jdbc4.AbstractJdbc4Connection.<init>(AbstractJdbc4Connection.java:32) at org.postgresql.jdbc4.Jdbc4Connection.<init>(Jdbc4Connection.java:24) at org.postgresql.Driver.makeConnection(Driver.java:393) at org.postgresql.Driver.connect(Driver.java:267) at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:322)

3 4

chanking mkIsoFs path
by Dan Kenigsberg 06 Sep '19

06 Sep '19

I bumped by accident on https://gerrit.ovirt.org/#/c/102698/ py3: mkimage: Remove md5 part in getFileName and I don't think it is right: if a VM is created in a 4.3 cluster and then migrated to a 4.4 cluster, qemu would not find the ISO image where it expects it, and it would break. I don't recall WHY we had md5 included into the path. It may well has been a mistake. I just do not see a (easy) backward-compatible way to drop it now.

3 2

[oVirt] [CQ weekly status] [30-08-2019]
by Dusan Fodor 30 Aug '19

30 Aug '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*: NOT RELEVANT This CQ is not followed anymore, since it's about to be decommissioned. *CQ-4.3*: YELLOW (#1) Last failure was on 28-08 for ovirt-web-ui. It was solved soon after by change 57c5c4b. *CQ-Master:* RED (#1) Last failure was on 30-08 for ovirt-engine in host-deployment. This issue is under investigation. 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-queue-tester/ [2] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -4.3_change-queue-tester/ [3] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -master_change-queue-tester/ Have a nice week! Dusan ------------------------------------------------------------------------------------------------------------------- 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) _______________________________________________ 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/YCNCKRK3G4EJXA3OCYAUS4VMKRDA67F4/

1 0

Failure adding host due to missing 'ovirt_host_deploy'
by Eyal Shenitzky 29 Aug '19

29 Aug '19

Hi all, I am failing to add a new host to oVirt environment, the engine runs on fedora-30. ovirt_host_deploy isn't found under - http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc30 I installed the fc29 version. *Error:* File "/tmp/ovirt-biYslZJETn/otopi-plugins/ovirt-host-deploy/kdump/packages.py", line 37, in <module> from ovirt_host_deploy import constants as odeploycons otopi.main.PluginLoadException: No module named 'ovirt_host_deploy *Installed packages:* ovirt-host-deploy-common-1.9.0-0.0.master.20190722100027.git138fb90.fc29.noarch python2-ovirt-host-deploy-1.9.0-0.0.master.20190722100027.git138fb90.fc29.noarch ovirt-host-deploy-common-1.9.0-0.0.master.20190722100027.git138fb90.fc29.noarch Does someone encounter that issue? Thanks, -- Regards, Eyal Shenitzky

3 4

Nominate Sharon and Michal as ovirt-engine-nodejs-modules maintainers
by Vojtech Szocs 28 Aug '19

28 Aug '19

Hi everyone, I'd like to nominate Sharon and Michal as ovirt-engine-nodejs-modules <https://gerrit.ovirt.org/#/admin/projects/ovirt-engine-nodejs-modules> project maintainers. This project is a build-time dependency of oVirt web-related projects, providing the required npm (JavaScript) dependencies via single RPM package. Projects that depend on ovirt-engine-nodejs-modules include (see here <https://gerrit.ovirt.org/gitweb?p=ovirt-engine-nodejs-modules.git;a=blob_pl…> for details): - ovirt-web-ui <https://github.com/oVirt/ovirt-web-ui> (next-gen User Portal) - ovirt-engine-ui-extensions <https://gerrit.ovirt.org/#/admin/projects/ovirt-engine-ui-extensions> (UI plugin for Admin Portal) - cockpit-ovirt <https://gerrit.ovirt.org/#/admin/projects/cockpit-ovirt> (plugins for Cockpit) Both Sharon and Michal are familiar with these projects and having them as maintainers would help with resolving any issues related to oVirt JS dependencies. Thanks, Vojtech

6 5

OST upgrade-from-release-suite-master update_cluster_versions failing
by Dominik Holler 28 Aug '19

28 Aug '19

Hi, for me OST upgrade-from-release-suite-master update_cluster_versions is failing with 004_basic_sanity.update_cluster_versions (from nosetests) Failing for the past 1 build (Since Failed#5442 ) Took 1 min 16 sec. add description Error Message Fault reason is "Operation Failed". Fault detail is "[Update of cluster compatibility version failed because there are VMs/Templates [vm-with-iface, vm-with-iface-template, vm0, vm1] with incorrect configuration. To fix the issue, please go to each of them, edit, change the Custom Compatibility Version of the VM/Template to the cluster level you want to update the cluster to and press OK. If the save does not pass, fix the dialog validation. After successful cluster update, you can revert your Custom Compatibility Version change.]". HTTP response code is 500. Stacktrace Traceback (most recent call last): 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 "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 79, in wrapper prefix.virt_env.engine_vm().get_api(api_ver=4), *args, **kwargs File "/home/jenkins/workspace/ovirt-system-tests_manual/ovirt-system-tests/upgrade-from-release-suite-master/test-scenarios-after-upgrade/004_basic_sanity.py", line 184, in update_cluster_versions minor=minor File "/home/jenkins/workspace/ovirt-system-tests_manual/ovirt-system-tests/upgrade-from-release-suite-master/test-scenarios-after-upgrade/004_basic_sanity.py", line 130, in _update_cluster_version version=new_version File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py", line 3943, in update return self._internal_update(cluster, headers, query, wait) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 253, in _internal_update return future.wait() if wait else future File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 55, in wait return self._code(response) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 250, in callback self._check_fault(response) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 132, in _check_fault self._raise_error(response, body) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 118, in _raise_error raise error Error: Fault reason is "Operation Failed". Fault detail is "[Update of cluster compatibility version failed because there are VMs/Templates [vm-with-iface, vm-with-iface-template, vm0, vm1] with incorrect configuration. To fix the issue, please go to each of them, edit, change the Custom Compatibility Version of the VM/Template to the cluster level you want to update the cluster to and press OK. If the save does not pass, fix the dialog validation. After successful cluster update, you can revert your Custom Compatibility Version change.]". HTTP response code is 500. Please find an example run in https://jenkins.ovirt.org/view/oVirt system tests/job/ovirt-system-tests_manual/5442 Is this a known error, or is someone already addressing this issue? Thanks Dominik

3 10

mailing list
by Hetz Ben Hamo 28 Aug '19

28 Aug '19

Hi, Any chance that someone will take a look at the ovirt mailing list server? Trying to access https://lists.ovirt.org/archives/list/devel%40ovirt.org/ gives error 500 Thanks תודה, *חץ בן חמו* אתם מוזמנים לבקר בבלוג היעוץ <http://linvirtstor.net/> או בבלוג הפרטי שלי <http://benhamo.org>

2 1

ovirt-engine has been tagged (ovirt-engine-4.3.6.4)
by Tal Nisan 27 Aug '19

27 Aug '19

1 0

CI fails - tox error
by Pavel Bar 26 Aug '19

26 Aug '19

Hi, We experience problems with failed CI on VDSM patches. Examples: http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10633/ http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10634/ http://jenkins.ovirt.org/job/vdsm_standard-check-patch/10635/ This is what we see in logs: out=`tox --version`; \ if [ $? -ne 0 ]; then \ echo "Error: cannot run tox, please install tox \ 2.9.1 or later"; \ exit 1; \ fi; \ version=`echo $out | cut -d' ' -f1`; \ if python2.7 build-aux/vercmp $version 2.9.1; then \ echo "Error: tox is too old, please install tox \ 2.9.1 or later"; \ exit 1; \ fi Traceback (most recent call last): File "/usr/bin/tox", line 7, in <module> from tox import cmdline File "/usr/lib/python2.7/site-packages/tox/__init__.py", line 4, in <module> from .hookspecs import hookimpl File "/usr/lib/python2.7/site-packages/tox/hookspecs.py", line 4, in <module> from pluggy import HookimplMarker File "/usr/lib/python2.7/site-packages/pluggy/__init__.py", line 16, in <module> from .manager import PluginManager, PluginValidationError File "/usr/lib/python2.7/site-packages/pluggy/manager.py", line 6, in <module> import importlib_metadata File "/usr/lib/python2.7/site-packages/importlib_metadata/__init__.py", line 9, in <module> import zipp File "/usr/lib/python2.7/site-packages/zipp.py", line 12, in <module> import more_itertools File "/usr/lib/python2.7/site-packages/more_itertools/__init__.py", line 1, in <module> from more_itertools.more import * # noqa File "/usr/lib/python2.7/site-packages/more_itertools/more.py", line 340 def _collate(*iterables, key=lambda a: a, reverse=False): ^ SyntaxError: invalid syntax Error: cannot run tox, please install tox 2.9.1 or later make: *** [tox] Error 1 + teardown + res=2 + '[' 2 -ne 0 ']' + echo '*** err: 2' *** err: 2 + collect_logs + tar --directory /var/log --exclude 'journal/*' -czf /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/mock_varlogs.tar.gz . + tar --directory /var/host_log --exclude 'journal/*' -czf /home/jenkins/workspace/vdsm_standard-check-patch/vdsm/exported-artifacts/host_varlogs.tar.gz . + teardown_storage + python2 tests/storage/userstorage.py teardown Can someone look at it? Thank you in advance! Pavel

3 3

[oVirt] [CQ weekly status] [25-08-2019]
by Dusan Fodor 25 Aug '19

25 Aug '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 (#2) Last failure was on 20-08 for ovirt-ansible-hosted-engine-setup. It was caused by random network issue (fetching repo from github), retriggered job for the change passed well. *CQ-4.3*: GREEN (#2) Last failure was on 20-08 for ovirt-ansible-hosted-engine-setup. It was caused by random network issue, retriggered job for the change passed well. *CQ-Master:* RED (#1) Last failure was on 25-08 for ovirt-engine, caused by failed cloning of engine repo (even with lately increased timeout value 20min). Related ticket from last time was reopened. 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-queue-tester/ [2] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -4.3_change-queue-tester/ [3] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -master_change-queue-tester/ Have a nice week! Dusan ------------------------------------------------------------------------------------------------------------------- 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) _______________________________________________ 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/YCNCKRK3G4EJXA3OCYAUS4VMKRDA67F4/

1 0

[feedback needed] CentOS guest images with pre-installed ovirt-guest-agent
by Sandro Bonazzola 22 Aug '19

22 Aug '19

Hi, please help CentOS Virtualization SIG testing https://buildlogs.centos.org/centos/images/ovirt/ if we can confirm they're working fine we'll have them built regularly with new CentOS releases. You can just reply here or directly to me with your feedback. Thanks, -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/>*Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

1 0

Relaunching the website migration project
by Marc Dequènes (Duck) 22 Aug '19

22 Aug '19

Quack, ### A pinch of history As a short introduction for those who do not know me as I rarely post here: I'm part of Red Hat OSPO Comminfra Team (previously OSPO was called OSAS) and currently hosting and taking care of the website. This topic has been discussed many times: neither people writing the site neither us for the maintenance are happy with the current state of affair. But we had not real plan and picking a random tool which might lead to similar problems and without any way to support it properly was not very appealing. Moreover we tried migrating to Middleman 4, the obvious path to modernization, but this happened to be more complicated than expected and this new version had terrible performance problems. As you now version 3 is already slow, and that's quite an understatement. In the meanwhile a few things have changed, and people taking care of the website too, so let's talk about the current situation. (very short version of the history around this) ### Why now? What has changed: * several projects moved to Jekyll, a software we were already investigating at the time and is being used by Google Pages (they created it in fact), and they were very happy with the result; we believe it has the necessary features, it is well maintained because Google uses it heavily, and it's very fast * we've tried Jekyll ourselves, we're happy too, and we do have the Ansible playbooks and tooling to deploy it now * over time the website had some waves of cleanup (still needs quite some love though) and recently the blog moved to WordPress to get comment support and a more friendly interface (see OVIRT-2652) which allowed more cleanup (see #2030) With the blog separated and a lot of custom Ruby code removed, the tooling ready, I believe we can now work on migrating the content. We may realize Jekyll is not the right tool, but people seemed to like the idea at the time and current experience seem to indicate it should improve things and be maintainable. The goal here is to experiment and switch to production only if we're happy with it. ### Early work I have started a branch called 'jekyll_migration' to put my work on it. This is very early work (I just started), I already hit various difficulties, and I can't commit 100% of my time on it so it will require some time. Several of my changes happened to not be really specific to the migration, and the current site would benefit from these fixes/cleanups/simplifications… thus I'll extracts these changes and create separate PRs for master. If you wish to help, then you can contact me directly or reply to this thread. You may also create PRs to this topic branch, but please do not push anything directly. Regards. \_o<

5 9

jenkins CI failing to fetch repo
by Miguel Duarte de Mora Barroso 22 Aug '19

22 Aug '19

Hi, Since yesterday I can't get ovirt-provider-ovn builds to run, each manifesting the error below: error: index-pack died of signal 15 09:27:35 fatal: index-pack failed 09:27:35 09:27:35 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2042) 09:27:35 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1761) 09:27:35 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$400(CliGitAPIImpl.java:72) 09:27:35 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:442) 09:27:35 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:655) 09:27:35 at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153) 09:27:35 at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146) 09:27:35 at hudson.remoting.UserRequest.perform(UserRequest.java:212) 09:27:35 at hudson.remoting.UserRequest.perform(UserRequest.java:54) 09:27:35 at hudson.remoting.Request$2.run(Request.java:369) 09:27:35 at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) 09:27:35 at java.util.concurrent.FutureTask.run(FutureTask.java:266) 09:27:35 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 09:27:35 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 09:27:35 at java.lang.Thread.run(Thread.java:748) 09:27:35 Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to vm0038.workers-phx.ovirt.org 09:27:35 at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743) 09:27:35 at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) 09:27:35 at hudson.remoting.Channel.call(Channel.java:957) 09:27:35 at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146) 09:27:35 at sun.reflect.GeneratedMethodAccessor793.invoke(Unknown Source) 09:27:35 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 09:27:35 at java.lang.reflect.Method.invoke(Method.java:498) 09:27:35 at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132) 09:27:35 at com.sun.proxy.$Proxy118.execute(Unknown Source) 09:27:35 at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1152) 09:27:35 at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192) 09:27:35 at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:124) 09:27:35 at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:93) 09:27:35 at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:80) 09:27:35 at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47) 09:27:35 at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 09:27:35 ... 4 more It can be seen on: - https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-check-patch/2476/…

2 2

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

21 Aug '19

Hi Martin, We finished a paper on open source projects' Coverity usage in May which will be published in ISSRE'19 <http://2019.issre.net/>. (Attached) Thanks for your help in giving me access to Coverity data. I'd love to hear your feedback on this whenever you have time. Also, based on your experience of using static analysis tools, I'd love to hear if you have any future research suggestions. Thanks again, Nasif

1 0

fun with ovirt ansible
by Fedor Gavrilov 20 Aug '19

20 Aug '19

I've been trying to reproduce an issue when it was possible, using ansible, to create an image in one dc with disk in another one. Since adding validation to ImportRepoImage command turned out to not be enough, this time I am trying to stick as close as possible to the original reproducer. OS is CentOS 7, ansible-playbook is 2.8.4 (latest, that is) I have this simplistic yml that references vars from the inventory file, like the following: - ovirt_auth: url: "{{engine_url}}" username: "{{engine_user}}" password: "{{engine_password}}" state: present insecure: true and the inventory file is very straightforward as well, just a bunch of vars: [local:vars] engine_url=https://apple/ovirt-engine/api engine_user=admin@internal engine_password=engine However, as I run this against my engine, which is latest master, ansible is able to login successfully and then fail with "msg": "The response content type 'text/html;charset=UTF-8' isn't the expected XML. Is the path '/ovirt-********/api' included in the 'url' parameter correct? The typical one is '/ovirt-engine/api'" This ovirt-******* is very intriguing. I sniffed the traffic and here is what is done, apparently: 2019-08-16 20:56:18 ::1 ::1 > POST apple:8080 /ovirt-engine/sso/oauth/token HTTP/1.1 - - 2019-08-16 20:56:18 ::1 ::1 < - - - HTTP/1.1 200 OK 2019-08-16 20:56:18 ::1 ::1 > GET apple:8080 /ovirt-********/api/templates?search=name%3Dfc28-cloud-test HTTP/1.1 - - 2019-08-16 20:56:18 ::1 ::1 < - - - HTTP/1.1 404 Not Found So it actually tries to reach /ovirt-********/api/templates?search=name%3Dfc28-cloud-test and gets 404 page. Once would think that something is wrong with ansible, but actually when I change engine url in inventory file to https://10-37-137-185.rhev.lab.eng.brq.redhat.com/ovirt-engine/api everthing runs fine. So I guess it's engine messing up the URL after all? Fedor

3 2

ovirt-engine has been tagged (ovirt-engine-4.3.6.3)
by Tal Nisan 20 Aug '19

20 Aug '19

1 0

vdsm has been tagged (v4.30.29)
by Petr Horacek 20 Aug '19

20 Aug '19

1 0

vdsm_standard-check-patch is stuck on Archiving artifacts
by Amit Bawer 19 Aug '19

19 Aug '19

Hi Unable to run CI builds and OSTs due to indefinite processing over fc29 Archiving artifacts phase Example run: https://jenkins.ovirt.org/job/vdsm_standard-check-patch/10453/console

5 11

Fwd: [CentOS-devel] SIG Content to remove for the 7.7.1908 release
by Sandro Bonazzola 19 Aug '19

19 Aug '19

FYI. ---------- Forwarded message --------- Da: Johnny Hughes <johnny(a)centos.org> Date: ven 16 ago 2019 alle ore 03:49 Subject: [CentOS-devel] SIG Content to remove for the 7.7.1908 release To: CentOS-Devel <centos-devel(a)centos.org> For all the c7 SIGs, if you have content that you want removed (to make inactive) when we create the new 7.7.1908 tree, please let me know here what needs to be removed. If all files in a specific directory can be removed, you can just list the directory. You will also obviously need to make any changes to your centos-release-* files to remove those file locations from your repos. After we release 7.7.1908 .. we will copy over the SIG directories prune the SIG content. The http://mirror.centos.org/centos/7/<repo>/ paths will then be shifted to the new 7.7.1908 tree. I expect that some time early next week we will release the CR content .. with the full release coming 7 to 14 days after that .. so full release likely some time between 29 August to 6 September 2019. If you don't tell us to remove content, we will move everything over as is. Thanks, Johnny Hughes _______________________________________________ CentOS-devel mailing list CentOS-devel(a)centos.org https://lists.centos.org/mailman/listinfo/centos-devel -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/>*Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours. <https://mojo.redhat.com/docs/DOC-1199578>*

1 0

How to copy snapshot of a disk from backup VM in ovirt to a storage area using scripting language with the help of api
by smidhunraj＠gmail.com 17 Aug '19

17 Aug '19

I have taken the snapshot of a virtual machine using rest API. I attached the disk to another backup vm in oVirt. 1) Is it possible using php to copy the backup of Virtual Machine to another storage . 2) How can i access a backup virtual machine in oVirt using bash script. Is it possible using some scripting language .Any reference to some script would be helpful. Thanks and regards, Midhun Raj S

2 1

VDSM OST fails on deployment
by Pavel Bar 15 Aug '19

15 Aug '19

Hi, https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5379/ Looks like the deployment stage of the OST run fails. Not related to the patch being tested.. Tried multiple times. Can someone have a look? Thank you in advance! Pavel

3 2

51 jobs in the queue, all workers are idle
by Nir Soffer 15 Aug '19

15 Aug '19

2 4

vdsm has been tagged (v4.30.28)
by Petr Horacek 14 Aug '19

14 Aug '19

1 0

NPE at Error during ValidateFailure at isVirtioScsiEnabled
by Yedidyah Bar David 14 Aug '19

14 Aug '19

Hi all, Engine failed for me twice on the manual job [1][2] with same error: 2019-08-08 14:47:01,737-04 ERROR [org.ovirt.engine.core.bll.AddVmFromScratchCommand] (default task-1) [390ae6e8-8047-40d3-bb6f-f5e57418320d] Error during ValidateFailure.: java.lang.NullPointerException at org.ovirt.engine.core.bll.AddVmCommand.isVirtioScsiEnabled(AddVmCommand.java:1725) [bll.jar:] at This is for a patch [3] that changes the PKCS#12 files in the engine CA. I can't see how this patch can cause this failure, and if it can, how come things do not fail earlier (e.g. when first opening the file or whatever). Can someone please have a look? Thanks. I'll now rebase the patch a third time and run the manual job, just in case it's an unrelated problem that's already fixed... Best regards, [1] https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… [2] https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… [3] https://gerrit.ovirt.org/102334 -- Didi

3 5

[ OST Failure Report ] [ oVirt Master (ovirt-engine) ] [ 10-07-2019 ] [ 002_bootstrap.add_blank_vms ]
by Dusan Fodor 13 Aug '19

13 Aug '19

Hi, We have a failure on test 002_bootstrap.add_blank_vms. CQ identifies this patch as the cause of failure: https://gerrit.ovirt.org/#/c/95157/14 Example of failed job: #15365 [1: 102575,2 (ovirt-engine)] <http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change…> Can you please take a look?

3 2

ovirt-engine has been tagged (ovirt-engine-4.3.6.2)
by Tal Nisan 13 Aug '19

13 Aug '19

1 0

Failed to add CentOS 7 host
by Fedor Gavrilov 13 Aug '19

13 Aug '19

Hi, Couple of days ago I had to refresh my dev environment to validate the issue and since support for Fedora 28 is no longer there I used CentOS 7 for both engine and host. Vdsm and cockpit socket on host is from the package, engine is compiled from git master. As I try to add new host, installment proceeds for quite a while but fails in the end, setting host to non operational. I see the following in the engine logs: 2019-08-12 17:32:40,341+02 INFO [org.ovirt.engine.core.bll.host.HostConnectivityChecker] (EE-ManagedThreadFactory-engine-Thread-20) [9f80a7] Engine managed to communicate with VDSM agent on host 'banana' with address 'banana' ('bcabbd09-81ef-422d-811c-3a18ac97919f') 2019-08-12 17:32:42,163+02 WARN [org.ovirt.engine.core.bll.network.NetworkConfigurator] (EE-ManagedThreadFactory-engine-Thread-20) [9f80a7] Failed to find a valid interface for the management network of host banana. If the interface null is a bridge, it should be torn-down manually. 2019-08-12 17:32:42,166+02 ERROR [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand] (EE-ManagedThreadFactory-engine-Thread-20) [9f80a7] Exception: org.ovirt.engine.core.bll.network.NetworkConfigurator$NetworkConfiguratorException: Interface null is invalid for management network at org.ovirt.engine.core.bll.network.NetworkConfigurator.findNicToSetupManagementNetwork(NetworkConfigurator.java:159) [bll.jar:] at org.ovirt.engine.core.bll.network.NetworkConfigurator.createManagementNetworkIfRequired(NetworkConfigurator.java:82) [bll.jar:] at org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand.configureManagementNetwork(InstallVdsInternalCommand.java:291) [bll.jar:] at org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand.installHost(InstallVdsInternalCommand.java:203) [bll.jar:] at org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand.executeCommand(InstallVdsInternalCommand.java:112) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1168) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1326) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:2005) [bll.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:164) [utils.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:103) [utils.jar:] at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1386) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:420) [bll.jar:] at org.ovirt.engine.core.bll.executor.DefaultBackendActionExecutor.execute(DefaultBackendActionExecutor.java:13) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:451) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:433) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:639) [bll.jar:] at sun.reflect.GeneratedMethodAccessor112.invoke(Unknown Source) [:1.8.0_222] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_222] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_222] at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) 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:79) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:89) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:102) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-17.0.1.Final.jar:17.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-17.0.1.Final.jar:17.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53) [wildfly-ejb3-17.0.1.Final.jar:17.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:216) [wildfly-ejb3-17.0.1.Final.jar:17.0.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:418) [wildfly-ejb3-17.0.1.Final.jar:17.0.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:148) [wildfly-ejb3-17.0.1.Final.jar:17.0.1.Final] 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.1.1.Final.jar:3.1.1.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.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-17.0.1.Final.jar:17.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) [wildfly-ejb3-17.0.1.Final.jar:17.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) [wildfly-ejb3-17.0.1.Final.jar:17.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) [wildfly-ejb3-17.0.1.Final.jar:17.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-17.0.1.Final.jar:17.0.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) [wildfly-ejb3-17.0.1.Final.jar:17.0.1.Final] 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.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:81) at org.ovirt.engine.core.bll.interfaces.BackendInternal$$$view3.runInternalAction(Unknown Source) [bll.jar:] at sun.reflect.GeneratedMethodAccessor111.invoke(Unknown Source) [:1.8.0_222] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_222] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_222] at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:410) [weld-core-impl-3.1.1.Final.jar:3.1.1.Final] at org.jboss.weld.module.ejb.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:134) [weld-ejb-3.1.1.Final.jar:3.1.1.Final] at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-3.1.1.Final.jar:3.1.1.Final] at org.jboss.weld.module.ejb.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:68) [weld-ejb-3.1.1.Final.jar:3.1.1.Final] at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:106) [weld-core-impl-3.1.1.Final.jar:3.1.1.Final] at org.ovirt.engine.core.bll.BackendCommandObjectsHandler$BackendInternal$BackendLocal$2049259618$Proxy$_$$_Weld$EnterpriseProxy$.runInternalAction(Unknown Source) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runInternalAction(CommandBase.java:2395) [bll.jar:] at org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand.lambda$executeCommand$3(AddVdsCommand.java:226) [bll.jar:] at org.ovirt.engine.core.utils.threadpool.ThreadPoolUtil$InternalWrapperRunnable.run(ThreadPoolUtil.java:96) [utils.jar:] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_222] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_222] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_222] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_222] at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_222] at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250) [javax.enterprise.concurrent-1.0.jar:] 2019-08-12 17:32:42,188+02 ERROR [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand] (EE-ManagedThreadFactory-engine-Thread-20) [9f80a7] Host installation failed for host 'bcabbd09-81ef-422d-811c-3a18ac97919f', 'banana': Failed to configure management network on the host ... 2019-08-12 17:35:01,502+02 ERROR [org.ovirt.engine.core.bll.SetNonOperationalVdsCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-85) [3c4801f1] Host 'banana' is set to Non-Operational, it is missing the following networks: 'ovirtmgmt' On host, sudo systemctl status vdsmd shows vdsm as active (running) with two concerning messages: авг 12 17:30:01 banana vdsm[2309]: WARN MOM not available. авг 12 17:30:01 banana vdsm[2309]: WARN MOM not available, KSM stats will be missing. I found a similar bug, https://bugzilla.redhat.com/show_bug.cgi?id=1676695 but it was fixed for 4.30 while on host I use 4.40.0-696 Have you seen such issue? Do you think networking error is related to MOM warnings? Setup I use is very much what worked perfectly fine for fedora and networking-vise the only questionable thing I am doing is having this kind of records in machine's /etc/hosts files to use names instead IPs (as imageio can't stand certificates with IPs): 192.168.111.2 apple 192.168.111.3 banana But this can't be the reason, right? Fedor

2 2

vdsm has been tagged (v4.30.27)
by Milan Zamazal 13 Aug '19

13 Aug '19

1 0

No response for post using curl for The Backup and Restore API oVirt API
by smidhunraj＠gmail.com 13 Aug '19

13 Aug '19

I have 2 virtual machines in my ovirt open virtualisation manager.The name of first virtual machine is backupvm and the name of second virtual machine is secondvm .I have created many snapshot shot of secondvm I want to convert a particular snapshot ofsecondvm using the ovirt api to secondvm backup and attach it to backupvm The link of the api is https://ovirt.org/documentation/admin-guide/chap-Backups_and_Migration.html… .I want to run the fourth step which says. Attach the snapshot to the backup virtual machine and activate the disk: POST /api/vms/22222222-2222-2222-2222-222222222222/disks/ HTTP/1.1 Accept: application/xml Content-type: application/xml <disk id="11111111-1111-1111-1111-111111111111"> <snapshot id="11111111-1111-1111-1111-111111111111"/> <active>true</active> </disk> .I want to attach this snapshots after converting them to backups of vms and then attach to vm named backupvm.The api for this is mentioned as The id of secondvm is a88a79ab-1f0c-4f32-bdaa-abc8109b3c0d and the id of backupvm is a88a79ab-1f0c-4f32-bdaa-abc8109b3c0d.The id of snapshot is 804cb937-5961-4a55-a453-74932c508dd6 and id of disk is e6c623e3-31d8-4554-ad5a-2b581914494b I have written a curl command for this as curl -u 'username:password' -H "Accept: application/xml" -H "Content-type: application/xml" -X POST -d '<disk id="e6c623e3-31d8-4554-ad5a-2b581914494b"> <snapshot id="804cb937-5961-4a55-a453-74932c508dd6"/> <active>true</active> </disk>' https:<url>/ovirt-engine/api/vms/a88a79ab-1f0c-4f32-bdaa-abc8109b3c0d/disks/ ; I expect the vm snapshot to be attached to backupvm.But i am not getting any response .Hence i am under the assumption that it is not working.. What modification should i make in the curl command to get it working In the figure below secondvm is labelled as bobcarenewvm https://i.stack.imgur.com/LC3An.png https://i.stack.imgur.com/Lgozu.png https://i.stack.imgur.com/efQrf.png https://i.stack.imgur.com/3wAyA.png Please help me, Thanks and Regards, Midhun.

3 3

[OST Failure Report] [oVirt master&4.3] [09-08-2019] [verify_glance_import]
by Dusan Fodor 12 Aug '19

12 Aug '19

Hi, we have failures in test verify glance import appearing in both 4.3 and master. Api call to get the disk status times out. Example of failed job can be seen here: https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.3_change-q… Can you please take a look?

3 3

Setting Start Running On Specific host radio button via the SDK
by donagh.moran＠oracle.com 12 Aug '19

12 Aug '19

Hi I'm looking to target the radio button for Specific host, Does anyone have info on what SDK object controls this feature? Even better if anyone can point me towards some documentation that maps oVirt UI functionality to the SDK endpoints? Best Regards Donagh

2 2

ovirt-host-deploy modifies the vdsm.conf
by Ales Musil 12 Aug '19

12 Aug '19

Hi, I have tried: /etc/ovirt-host-deploy.conf.d/50-development.conf [environment:enforce] VDSM/configOverride=bool:False But the vdsm config is still being modified by the host deploy any idea what is wrong with this configuration? Thank you. Regards, Ales -- Ales Musil Associate Software Engineer - RHV Network Red Hat EMEA <https://www.redhat.com> amusil(a)redhat.com IM: amusil <https://red.ht/sig>

1 1

Setting Migration Mode via SDK
by donagh.moran＠oracle.com 12 Aug '19

12 Aug '19

Hi In the VM Host settings, I need to set Migration mode ( Migration Options ) to "Do not allow migration" from the SDK but I do not see any functionality that would allow me to preform this task. Is there any method available that would let me achieve this from my Java code? Any help would be much appreciated. Best Regards Don

2 2

No response for post using curl for The Backup and Restore API oVirt API
by smidhunraj＠gmail.com 12 Aug '19

12 Aug '19

I have 2 virtual machines in my ovirt open virtualisation manager.The name of first virtual machine is backupvm and the name of second virtual machine is secondvm .I have created many snapshot shot of secondvm I want to convert a particular snapshot ofsecondvm using the ovirt api to secondvm backup and attach it to backupvm The link of the api is https://ovirt.org/documentation/admin-guide/chap-Backups_and_Migration.html… .I want to run the fourth step which says. Attach the snapshot to the backup virtual machine and activate the disk: POST /api/vms/22222222-2222-2222-2222-222222222222/disks/ HTTP/1.1 Accept: application/xml Content-type: application/xml <disk id="11111111-1111-1111-1111-111111111111"> <snapshot id="11111111-1111-1111-1111-111111111111"/> <active>true</active> </disk> .I want to attach this snapshots after converting them to backups of vms and then attach to vm named backupvm.The api for this is mentioned as The id of secondvm is a88a79ab-1f0c-4f32-bdaa-abc8109b3c0d and the id of backupvm is a88a79ab-1f0c-4f32-bdaa-abc8109b3c0d.The id of snapshot is 804cb937-5961-4a55-a453-74932c508dd6 and id of disk is e6c623e3-31d8-4554-ad5a-2b581914494b I have written a curl command for this as curl -u 'username:password' -H "Accept: application/xml" -H "Content-type: application/xml" -X POST -d '<disk id="e6c623e3-31d8-4554-ad5a-2b581914494b"> <snapshot id="804cb937-5961-4a55-a453-74932c508dd6"/> <active>true</active> </disk>' https:<url>/ovirt-engine/api/vms/a88a79ab-1f0c-4f32-bdaa-abc8109b3c0d/disks/ ; I expect the vm snapshot to be attached to backupvm.But i am not getting any response .Hence i am under the assumption that it is not working.. What modification should i make in the curl command to get it working In the figure below secondvm is labelled as bobcarenewvm https://i.stack.imgur.com/LC3An.png https://i.stack.imgur.com/Lgozu.png https://i.stack.imgur.com/efQrf.png https://i.stack.imgur.com/3wAyA.png Please help me, Thanks and Regards, Midhun.

1 0

[Ovirt] [CQ weekly status] [10-08-2019]
by Dusan Fodor 11 Aug '19

11 Aug '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 (#3) No failure during this week. *CQ-4.3*: RED (#1) Last failure was on 10-08 for ovirt-ansible-image-template in verify_glance_import. This issue is ongoing, investigation will continue under thread [OST Failure Report] [oVirt master&4.3] [09-08-2019] [verify_glance_import] *CQ-Master:* RED (#1) Last failure was on 10-08 for ovirt-ansible-image-template in verify_glance_import. This issue is ongoing, investigation will continue under thread [OST Failure Report] [oVirt master&4.3] [09-08-2019] [verify_glance_import] 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-queue-tester/ [2] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -4.3_change-queue-tester/ [3] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -master_change-queue-tester/ Have a nice week! Dusan ------------------------------------------------------------------------------------------------------------------- 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) _______________________________________________ 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/YCNCKRK3G4EJXA3OCYAUS4VMKRDA67F4/

2 1

CI: vdsm-standard-check-patch fails
by Amit Bawer 09 Aug '19

09 Aug '19

Hi, CI seems to fail constantly for unavailable remote gerrit repository. Example can be seen here: https://jenkins.ovirt.org/job/vdsm_standard-check-patch/9415/console

6 20

donagh.moran@oracle.com
by donagh.moran＠oracle.com 09 Aug '19

09 Aug '19

Email address in subject Best Regards Donagh

1 0

Ovirt Manager - FATAL: the database system is in recovery mode
by Sameer Sardar 08 Aug '19

08 Aug '19

PACKAGE_NAME="ovirt-engine" PACKAGE_VERSION="3.6.2.6" PACKAGE_DISPLAY_VERSION="3.6.2.6-1.el6" OPERATING SYSTEM="CentOS 6.7" Its been running error-free for over 3 years now. Over the past few weeks, the Ovirt manager application has been frequently losing connection with its own database residing on the same server. It is throwing up errors saying: “Caused by org.postgresql.util.PSQLException: FATAL: the database system is in recovery mode”. The only means we have found to recover from this is to hard reboot the server, after which it works fine for a couple of days before throwing up these errors again. Here are some logs : Caused by: org.postgresql.util.PSQLException: FATAL: the database system is in recovery mode at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:293) at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:108) at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66) at org.postgresql.jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java:125) at org.postgresql.jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Connection.java:30) at org.postgresql.jdbc3g.AbstractJdbc3gConnection.<init>(AbstractJdbc3gConnection.java:22) at org.postgresql.jdbc4.AbstractJdbc4Connection.<init>(AbstractJdbc4Connection.java:32) at org.postgresql.jdbc4.Jdbc4Connection.<init>(Jdbc4Connection.java:24) at org.postgresql.Driver.makeConnection(Driver.java:393) at org.postgresql.Driver.connect(Driver.java:267) at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:322)

1 0

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

Failure during OST run
by Andrej Cernek 07 Aug '19

07 Aug '19

Hi, I am failing at running ost: * [Thread-2] Deploy VM lago-network-suite-master-engine: ERROR (in 0:02:13) # Deploy environment: ERROR (in 0:02:14) @ Deploy oVirt environment: ERROR (in 0:02:14) The error seems to be caused by unavailable package: Error: Package: ovirt-engine-metrics-1.3.4-0.0.master.20190804083458.git68b317a.el7.noarch (alocalsync) Requires: ansible >= 2.8.3 Available: ansible-2.4.2.0-2.el7.noarch (extras) ansible = 2.4.2.0-2.el7 Installing: ansible-2.8.2-1.el7.noarch (alocalsync) ansible = 2.8.2-1.el7 Did anyone encounter similar issues? Thanks, Regards, Andrej

3 2

ovirt-engine has been tagged (ovirt-engine-4.3.6.1)
by Tal Nisan 06 Aug '19

06 Aug '19

1 0

vdsm has been tagged (v4.30.26)
by Milan Zamazal 06 Aug '19

06 Aug '19

1 0

[Ovirt] [CQ weekly status] [02-08-2019]
by Dusan Fodor 05 Aug '19

05 Aug '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*: RED (#1) Last failure was on 01-08 for ovirt-ansible-hosted-engine-setup caused by missing dependency, patch is pending to fix this. *CQ-4.3*: RED (#1) Last failure was on 02-08 for vdsm caused by missing dependency, patch is pending to fix this. *CQ-Master:* RED (#1) Last failure was on 02-08 for ovirt-engine due failure in build-artifacts, which was caused by gerrit issue, which was reported Evgheni. 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… Have a nice week! Dusan ------------------------------------------------------------------------------------------------------------------- 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) _______________________________________________ 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/YCNCKRK3G4EJX…

5 5

Network tests failing randomly again: AssertionError: '192.168.98.1/29' unexpectedly found in ['192.168.99.1/29', '192.168.98.1/29', 'fe80::3c92:48ff:fecd:8366/64']
by Nir Soffer 05 Aug '19

05 Aug '19

This used to happen randomly in the past, and started to happen again. I can ignore this failure and merge, but this may fail the change queue. Build: https://jenkins.ovirt.org/job/vdsm_standard-check-patch/9520//artifact/chec… ====================================================================== FAIL: test_add_delete_ipv4 (network.ip_address_test.IPAddressTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/network/ip_address_test.py", line 222, in test_add_delete_ipv4 self._test_add_delete(IPV4_A_WITH_PREFIXLEN, IPV4_B_WITH_PREFIXLEN) File "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/network/ip_address_test.py", line 247, in _test_add_delete self._assert_has_no_address(nic, ip_b) File "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/network/ip_address_test.py", line 344, in _assert_has_no_address self._assert_address_not_in(address_with_prefixlen, addresses) File "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/network/ip_address_test.py", line 352, in _assert_address_not_in self.assertNotIn(address_with_prefixlen, addresses_list) AssertionError: '192.168.98.1/29' unexpectedly found in ['192.168.99.1/29', '192.168.98.1/29', 'fe80::3c92:48ff:fecd:8366/64'] -------------------- >> begin captured logging << -------------------- 2019-08-05 12:27:49,718 DEBUG (MainThread) [root] /sbin/ip link add name dummy_GmE1I type dummy (cwd None) (cmdutils:130) 2019-08-05 12:27:49,731 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (cmdutils:138) 2019-08-05 12:27:49,733 DEBUG (netlink/events) [root] START thread <Thread(netlink/events, started daemon 140511381804800)> (func=<bound method Monitor._scan of <vdsm.network.netlink.monitor.Monitor object at 0x7fcb7bbfd0d0>>, args=(), kwargs={}) (concurrent:193) 2019-08-05 12:27:49,734 DEBUG (MainThread) [root] /sbin/ip link set dev dummy_GmE1I up (cwd None) (cmdutils:130) 2019-08-05 12:27:49,746 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (cmdutils:138) 2019-08-05 12:27:49,749 DEBUG (netlink/events) [root] FINISH thread <Thread(netlink/events, started daemon 140511381804800)> (concurrent:196) 2019-08-05 12:27:49,755 DEBUG (MainThread) [root] /sbin/ip -4 addr add dev dummy_GmE1I 192.168.99.1/29 (cwd None) (cmdutils:130) 2019-08-05 12:27:49,763 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (cmdutils:138) 2019-08-05 12:27:49,767 DEBUG (MainThread) [root] /sbin/ip -4 addr add dev dummy_GmE1I 192.168.98.1/29 (cwd None) (cmdutils:130) 2019-08-05 12:27:49,778 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (cmdutils:138) 2019-08-05 12:27:49,785 DEBUG (MainThread) [root] /sbin/ip -4 addr del dev dummy_GmE1I 192.168.98.1/29 (cwd None) (cmdutils:130) 2019-08-05 12:27:49,796 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (cmdutils:138) 2019-08-05 12:27:49,803 DEBUG (MainThread) [root] /sbin/ip link del dev dummy_GmE1I (cwd None) (cmdutils:130) 2019-08-05 12:27:49,824 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (cmdutils:138)

1 0