- Devel - oVirt List Archives

"No module named pathlib" errors in OST
by Marcin Sobczyk 24 Nov '20

24 Nov '20

Hi, there was a new version of 'importlib_metadata' library pushed to pypi. Even though it's compatible only with py3, it's picked up by py2 pip. I posted a patch to fix the version to the previous one: https://gerrit.ovirt.org/#/c/112325/ If you see this failure in other suites than basic please notify me and I will align the patch. Regards, Marcin

2 1

Branching out 4.3 in ovirt-system-tests
by Marcin Sobczyk 23 Nov '20

23 Nov '20

Hi all, after minimizing the usage of lago in basic suite, and some minor adjustments in the network suite, we are finally able to remove lago OST plugin as a dependency [1]. This however comes with a price of keeping lots of ugly ifology, i.e. [2][3]. There's big disparity between OST runs we have on el7 and el8. There's also tons of symlink-based code sharing between suites - be it 4.3 suites and master suites or simply different types of suites. The basic suite has its own 'test_utils', which is copied/symlinked in multiple places. There's also 'ost_utils', which is really messy ATM. It's very hard to keep track and maintain all of this... At this moment, we are able to run basic suite and network suite on el8, with prebuilt ost-images and without lago plugin. HE suites should be the next step. We have patches that make them py3-compatible that probably still need some attention [4][5]. We don't have any prebuilt HE ost-images, but this will be handled in the nearest future. I think it's good time to detach ourselves from the legacy stuff and start with a clean slate. My proposition would be to branch out 4.3 in ovirt-system-tests and not use py2/el7 in the master branch at all. This would allow us to focus on py3, el8 and ost-images efforts while keeping the legacy stuff intact. WDYT? Regards, Marcin [1] https://gerrit.ovirt.org/#/c/111643/ [2] https://gerrit.ovirt.org/#/c/111643/6/basic-suite-master/control.sh [3] https://gerrit.ovirt.org/#/c/111643/6/basic-suite-master/test-scenarios/con… [4] https://gerrit.ovirt.org/108809 [5] https://gerrit.ovirt.org/110097

3 8

Can't find storage server connection
by francesco＠shellrent.com 23 Nov '20

23 Nov '20

Hi all, I'm using oVirt SDK python for retrieving info about storage domain, in several hosts (centos7/ovirt4.3 and centos8/ovirt4.4), but the script exits with the following error in some of them: Traceback (most recent call last): File "get_uuid.py", line 70, in <module> storage_domain = sds_service.list(search='name=data-foo')[0] File "/root/.local/lib/python2.7/site-packages/ovirtsdk4/services.py", line 26296, in list return self._internal_get(headers, query, wait) File "/root/.local/lib/python2.7/site-packages/ovirtsdk4/service.py", line 211, in _internal_get return future.wait() if wait else future File "/root/.local/lib/python2.7/site-packages/ovirtsdk4/service.py", line 55, in wait return self._code(response) File "/root/.local/lib/python2.7/site-packages/ovirtsdk4/service.py", line 208, in callback self._check_fault(response) File "/root/.local/lib/python2.7/site-packages/ovirtsdk4/service.py", line 132, in _check_fault self._raise_error(response, body) File "/root/.local/lib/python2.7/site-packages/ovirtsdk4/service.py", line 118, in _raise_error raise error ovirtsdk4.Error: Fault reason is "Operation Failed". Fault detail is "Can't find storage server connection for id '92444a95-0be7-4589-ac46-1ed6dfe7ed4c'.". HTTP response code is 500. The portion of the script that search for the storage domain is the following: sds_service = connection.system_service().storage_domains_service() storage_domain = sds_service.list(search='name={}'.format(storage_domain_name))[0] Now: I have no real clue on which ID "92444a95-0be7-4589-ac46-1ed6dfe7ed4c'" but digging in the engine logs it refers to StorageServerConnections ID: [root@ovirt-engine ovirt-engine]# zgrep 92444a95-0be7-4589-ac46-1ed6dfe7ed4c *.gz engine.log-20201108.gz:2020-11-07 06:05:54,352+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-79) [3ffb810c] START, ConnectStorageServerVDSCommand(HostName = another-server.foo.com, StorageServerConnectionManagementVDSParameters:{hostId='7d202bc7-002b-4426-8446-99b6b346874e', storagePoolId='82d0b3de-0334-451c-8321-c3533de9a894', storageType='LOCALFS', connectionList='[StorageServerConnections:{id='92444a95-0be7-4589-ac46-1ed6dfe7ed4c', connection='/data', iqn='null', vfsType='null', mountOptions='null', nfsVersion='null', nfsRetrans='null', nfsTimeo='null', iface='null', netIfaceName='null'}]', sendNetworkEventOnFailure='true'}), log id: 1509fe17 As I said, I tried to execute the script from several hosts: some of them with oVirt 4.3 and other with oVirt 4.4 but it can run, or not, on both of versions. I also did the following test: I tried execute the script on different host passing different data storage: - let's say that on host foo-host1, executing the script querying for its own data storage named foo-data1 works correctly; - and let's say that on host foo-host2, the same script querying for its own data storage foo-data2 return the mentioned error; If I execute the script on foo-host2 querying the foo-data1 domain data, I got the error. If I execute on foo-host1 querying foo-data2, I still got the error. When I try to manage the storage domain via ovirt-engine GUI on the hosts that the script exit with the mentioned error, I recieve the following error: Uncaught exception occurred. Please try reloading the page. Details: (TypeError) : Cannot read property 'a' of null Please have your administrator check the UI logs The logs: 2020-11-23 09:59:31,934+01 ERROR [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService] (default task-239) [] Permutation name: 68A62BEB12822F65FE66B14A9E16480A 2020-11-23 09:59:31,934+01 ERROR [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService] (default task-239) [] Uncaught exception: com.google.gwt.core.client.JavaScriptException: (TypeError) : Cannot read property 'a' of null at org.ovirt.engine.ui.uicommonweb.models.storage.FileStorageModel.$lambda$0(FileStorageModel.java:34) at org.ovirt.engine.ui.uicommonweb.models.storage.FileStorageModel$lambda$0$Type.onSuccess(FileStorageModel.java:34) at org.ovirt.engine.ui.frontend.Frontend$1.$onSuccess(Frontend.java:227) at org.ovirt.engine.ui.frontend.Frontend$1.onSuccess(Frontend.java:227) at org.ovirt.engine.ui.frontend.communication.OperationProcessor$1.$onSuccess(OperationProcessor.java:133) at org.ovirt.engine.ui.frontend.communication.OperationProcessor$1.onSuccess(OperationProcessor.java:133) at org.ovirt.engine.ui.frontend.communication.GWTRPCCommunicationProvider$5$1.$onSuccess(GWTRPCCommunicationProvider.java:270) at org.ovirt.engine.ui.frontend.communication.GWTRPCCommunicationProvider$5$1.onSuccess(GWTRPCCommunicationProvider.java:270) at com.google.gwt.user.client.rpc.impl.RequestCallbackAdapter.onResponseReceived(RequestCallbackAdapter.java:198) at com.google.gwt.http.client.Request.$fireOnResponseReceived(Request.java:233) at com.google.gwt.http.client.RequestBuilder$1.onReadyStateChange(RequestBuilder.java:409) at Unknown.eval(webadmin-0.js) at com.google.gwt.core.client.impl.Impl.apply(Impl.java:306) at com.google.gwt.core.client.impl.Impl.entry0(Impl.java:345) at Unknown.eval(webadmin-0.js) Any slightest idea on what is going on? Thank you for your time and help, Francesco

1 0

[OST] Testing master suite on using python 2.7?!
by Nir Soffer 19 Nov '20

19 Nov '20

I'm trying to add a test module for image transfer: https://gerrit.ovirt.org/c/112274/ The test use concurrent.futures module form the standard library. This module is not available in python 2.7 but we don't support 2.7 in master and it was EOL since Jan 2020. The test fail when starting the suite: [2020-11-18T16:17:10.526Z] ============================= test session starts ============================== [2020-11-18T16:17:10.526Z] platform linux2 -- Python 2.7.5, pytest-4.6.9, py-1.9.0, pluggy-0.13.1 -- /usr/bin/python2 ... [2020-11-18T16:17:11.105Z] ==================================== ERRORS ==================================== [2020-11-18T16:17:11.105Z] ___ ERROR collecting basic-suite-master/test-scenarios/008_image_transfer.py ___ [2020-11-18T16:17:11.105Z] ImportError while importing test module '/home/jenkins/agent/workspace/ovirt-system-tests_standard-check-patch/ovirt-system-tests/basic-suite-master/test-scenarios/008_image_transfer.py' [2020-11-18T16:17:11.105Z] Hint: make sure your test modules/packages have valid Python names. [2020-11-18T16:17:11.105Z] Traceback: [2020-11-18T16:17:11.105Z] ../basic-suite-master/test-scenarios/008_image_transfer.py:22: in <module> [2020-11-18T16:17:11.105Z] import concurrent.futures [2020-11-18T16:17:11.105Z] E ImportError: No module named concurrent.futures Should we use pytest.skip() to skip this test when running on python 2? Or just remove the python 2 build, I don't have any idea why we run master code python 2. Nir

2 3

vdsm CI is failing
by Marcin Sobczyk 18 Nov '20

18 Nov '20

Hi, vdsm CI is failing with: [2020-11-16T10:51:40.132Z] No match for argument: ovirt-imageio-client-2.1.1 [2020-11-16T10:51:40.132Z] Error: Unable to find a match: ovirt-imageio-client-2.1.1 example run: https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa… could you please take a look at it? Regards, Marcin

3 3

ovirt-engine has been tagged (ovirt-engine-4.4.4.1)
by Tal Nisan 18 Nov '20

18 Nov '20

1 0

About cluster level 4.5 and oVirt 4.4.3 release notes
by Sandro Bonazzola 18 Nov '20

18 Nov '20

Hi, it has been raised today on #ovirt channel that there's no mention of the 4.5 cluster level new features and about its requirements on RHEL 8.3 in release notes at https://ovirt.org/release/4.4.3/ Can you please send an update to the oVirt website adding the missing information? 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. <https://mojo.redhat.com/docs/DOC-1199578>*

2 5

[OST] Network suites fail CI builds
by Nir Soffer 17 Nov '20

17 Nov '20

I had many failures in recent OST patches, so I posted this change: https://gerrit.ovirt.org/c/112174/ This patch does not change anything, but it modifies the lago vm configuration so it triggers 8 jobs. 2 network test suites failed: https://jenkins.ovirt.org/blue/organizations/jenkins/ovirt-system-tests_sta… Can someone look at the network suite failures? If these suites are not stable, we should not included them in the CI for OST patches, or mark them as expected failures so they do not fail the build. I triggered another build since I see lot of random failures in other suites. Nir

4 6

expect OST failures on el8 for the next couple of hours
by Marcin Sobczyk 16 Nov '20

16 Nov '20

Hi all, while working on cleanup procedures for ost-images I accidentally removed the RPMs from the templates server. Not my day... I'm rebuilding them right now and will republish them ASAP, but you if you try running el8-based basic/networking suites you will probably end up with a failure. Hopefully when the cleanup patch is ready I will never have to do this manually again and will avoid mistakes like this in the future. Very sorry for the inconvenience. Regards, Marcin

1 0

bz 1875386 openssl conf files point at qemu-ca-certificate: status
by Yedidyah Bar David 15 Nov '20

15 Nov '20

Hi all, I now finished verifying my patches, currently pushed to github [1]. Verified clean engine-setup and engine-setup upgrade from current master. Didn't verify adding hosts nor encrypted migration between them, but I think it should work. With the top patch there, also verified pki-enroll-pkcs12.sh, which verifies also pki-enroll-request.sh, with both default and --ca-file=qemu-ca. Now: Currently, that's 16 patches. The entire stack diff ('git diff' from master) is 580 lines, whereas with the current split ('git log '--format=%h %s' -u' from master) it's 1045 lines (~ twice), but perhaps easier to follow, and shows my thought/refinement process, although probably many comments you might have on earlier patches I already addressed in later ones. I also do not think we must have all 16 patches add all the extra load on CI, so didn't yet push to gerrit. So I wonder if just to squash them to a single one, or something in between, both for review and for eventual merging. We definitely need all of them merged at once, or if we want to prevent breakage and still merge splitted, quite a lot more work (which I don't have time for). Comments are welcome. [1] https://github.com/didib/ovirt-engine/commits/qemu-ca-fixes Best regards, -- Didi

2 2