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