June 2019 - Devel - oVirt List Archives

ovirt-system-tests_hc-basic-suite-master failing
by Gobinda Das 15 Jun '19

15 Jun '19

Hi, hc-basic-suite-master build is failing due to sanlock-python dependency issue. Error: Package: vdsm-4.40.0-338.gitaaf7f44.el7.x86_64 (alocalsync) Requires: sanlock-python >= 3.7.3 Installing: sanlock-python-3.6.0-1.el7.x86_64 (alocalsync) sanlock-python = 3.6.0-1.el7 Can anyone please help? -- Thanks, Gobinda

2 1

[Ovirt] [CQ weekly status] [14-06-2019]
by Dafna Ron 14 Jun '19

14 Jun '19

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) Last failure was on 05-06 for project ovirt-ansible-cluster-upgrade due to failure in test 002_bootstrap.add_master_storage_domain. The fix was created and merged *CQ-4.3*: GREEN (#1) There were two main failures this week. 1. vdsm was failing due to the sos change which was causing metrics tests to fail as it was using vdsm sos plugin and that is no longer available. this was fix by mperina: https://gerrit.ovirt.org/100716 https://gerrit.ovirt.org/100809 2. there was a general failure due to packages. two patches were merged to fix the issue: https://gerrit.ovirt.org/#/c/100764/ https://gerrit.ovirt.org/#/c/100691/ *CQ-Master:* GREEN (#1) Master was failing on the same issues as in 4.3 which are now fixed Current running jobs for 4.2 [1], 4.3 [2] and master [3] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.2_change-qu… [2] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.3_change-q… [3] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change… Happy week! Dafna ------------------------------------------------------------------------------------------------------------------- COLOUR MAP Green = job has been passing successfully ** green for more than 3 days may suggest we need a review of our test coverage 1. 1-3 days GREEN (#1) 2. 4-7 days GREEN (#2) 3. Over 7 days GREEN (#3) Yellow = intermittent failures for different projects but no lasting or current regressions ** intermittent would be a healthy project as we expect a number of failures during the week ** I will not report any of the solved failures or regressions. 1. Solved job failures YELLOW (#1) 2. Solved regressions YELLOW (#2) Red = job has been failing ** Active Failures. The colour will change based on the amount of time the project/s has been broken. Only active regressions would be reported. 1. 1-3 days RED (#1) 2. 4-7 days RED (#2) 3. Over 7 days RED (#3)

1 0

adding host to oVirt issue
by Hetz Ben Hamo 14 Jun '19

14 Jun '19

Hi, I have been checking oVirt latest (4.3.4) with adding various bare metal hosts with various CPU's: I'm asking on this mailing list if I should open a ticket and if so what ticket (bug? RFE?). - AMD Ryzen 5 - Xeon SP (first gen) - Xeon SP (second gen) - Upcoming unannounced Xeon CPU. The main oVirt machine (and the HE) is running on Xeon E3-1225 V3 CPU. The big problem is that when you add for example any AMD processor (whatever it's a low end Ryzen 5 or a high end 32 cores EPYC) to such a setup, it will fail because it tries to add the AMD machine to the default cluster which is defined as Intel based VT-X. If I'll try to add any non Xeon V3 CPU, it will succeed, but any live migration of VM's inside the cluster will fail since any Xeon chip version has various VT flags. So, my suggestion is that when adding nodes/hosts to oVirt, they will be added to a new "non clustered" place without any features allowed (live migration, for example) and after the admin will add the machines, he/she can assign nodes to a defined cluster (prepared or that he/she can create) Another problem with cluster defining is that the CPU type is too complicated for any admin who doesn't know the nuts and bolts of each CPU. For example - the Haswell CPU type got *6* CPU types. Do you really expect an admin to know which one to select? IMHO, a good solution would be to add some "detect" button to hosts, and the result from clicking this button should be a window with options like: - Add this host to an existing cluster (which has the same CPU type) - Auto create a new cluster with the CPU type detected from the node/host CPU I'll be happy to hear your thoughts about this issue. Thanks, Hetz

1 0

[ OST Failure Report ] [ oVirt Master (vdsm) ] [ 07-06-2019 ] [ 003_00_metrics_bootstrap.metrics_and_log_collector ]
by Dafna Ron 14 Jun '19

14 Jun '19

Hi, We have a failure in vdsm project on master. The issue is change: https://gerrit.ovirt.org/#/c/100576/ - Remove SOS VDSM plugin which is failing on metrics as metrics is calling sos-logcollector. The patch cannot be changed as until centos 7.7 when sos-3.7-3, which contains vdsm plugin will come out. so until then, we are left with no sos plugin, which is causing the metrics test to fail. Shirly, can you please take a look and see if we can change the test to not call sos-logcollector? Please note, that we are expecting 4.3 to fail on same issue very soon. failed job can be found here: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/14452/ ERROR from test: lago.ssh: DEBUG: Command 8626fe70 on lago-basic-suite-master-engine errors: ERROR: Failed to get a sosreport from: lago-basic-suite-master-host-1; Could not parse sosreport output ERROR: Failed to get a sosreport from: lago-basic-suite-master-host-0; Could not parse sosreport output lago.utils: DEBUG: Error while running thread Thread-3 Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in _ret_via_queue queue.put({'return': func()}) File "/home/jenkins/workspace/ovirt-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/003_00_metrics_bootstrap.py", line 97, in run_log_collector 'log collector failed. Exit code is %s' % result.code File "/usr/lib64/python2.7/unittest/case.py", line 462, in assertTrue raise self.failureException(msg) AssertionError: log collector failed. Exit code is 1 --------------------- >> end captured logging << ---------- Thanks, Dafna

7 21

Host installation error
by Charles Thao 13 Jun '19

13 Jun '19

Hi, I have a 4.3 engine on Fedora 28 laptop and a 4.3 node running on a virt-manager. I installed ovirt-node using the latest stable ISO image. When I tried to connect the host to my engine, this error appeared: *Host node installation failed. Failed to execute Ansible host-deploy role.* I've also attached an example log file. Has anyone seen anything similar to this? Regards, Charles T

1 0

Dropping Fedora 28 support in oVirt development repos and jenkins
by Sandro Bonazzola 13 Jun '19

13 Jun '19

Hi, while we are introducing support for fedora 29 and 30 we need to free resources both on jenkins and on resources.ovirt.org. Starting today I'll start pushing removal of fc28 jenkins jobs. Once done, I'm going to remove the fc28 repositories from all snapshot and tested repos, keeping fc28 repos only within the released repositories. Thanks, -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

4 9

Sanlock 3.8.0-1 for Fedora 30 is available for testing
by Nir Soffer 13 Jun '19

13 Jun '19

Whats new in 3.8.0? - Supports python 2.7, 3.6, 3.7, 3.8 - Built for python 3 only You can grab it here now: https://koji.fedoraproject.org/koji/buildinfo?buildID=1286742 It should be available tomorrow in updates-testing repo. Please test and leave feedback here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-7612da9fe7 Nir

1 0

Issues when running VDSM tests
by Pavel Bar 12 Jun '19

12 Jun '19

Hi Milan, Can you please check the following VDSM tests's failures: *Environment:* 1) VDSM master branch; 2) Fedora 29 OS *Execution (from root folder):* *make check* *Issues:* 1) An authentication pop-up window jumps when executing: *Warning no default label for /tmp/tmpRCRsYm/libvirtd.............................................................SS.........................................S.SS..S................S.S..................................................................SSS..SSSSS..SSSSSSS.................SSS..SSS...S..............SSSS..SS.....S.........SSSSS.S.S.........................SSSSS....SSSSSS......................................S..SSSSSSSSS.SS.........................................................................................................................................................................----------------------------------------------------------------------* 2) 2 error outputs received, the 2nd one multiple times: *ERROR: InvocationError for command '/home/pbar/Dev/git/vdsm/pbar/master/tests/profile network-py27 ./py-watch 600 pytest --durations=5 --cov=vdsm.network --cov-report=html:htmlcov-network-py27 --cov-fail-under=42 network/integration network/unit' (exited with code 1)* *E HookError: Hook Error: ('Traceback (most recent call last):\n File "/usr/libexec/vdsm/hooks/before_nic_hotplug/50_vmfex", line 35, in <module>\n from vdsm import libvirtconnection\nImportError: cannot import name libvirtconnection\n',)../lib/vdsm/common/hooks.py:124: HookError* Thank you in advance! Pavel

2 1

Building python 2 and python 3 packages for Fedora
by Nir Soffer 12 Jun '19

12 Jun '19

In several projects (e.g. vdsm, imageio, sanlock), we have the issue of building python 3 packages for Fedora. The current build process create packages with the same name for both python 2 and python 3. When the packages are published to oVirt repository, the python 3 packages overwrite the python 2 packages. We can rename the packages properly (e.g. python2-xxx, python3-xxx) but this requires lot of work and typically breaks later in the code publishing the packages. There is also the difficulty of building both python 2 and python 3 packages from same spec in the same build. This should be possible but not easy. Since python 2 is about to die soon, should we simplify by building python 2 *or* python 3, depending on version? Fedora 29: python 2.7 Fedora 30: python 3.7 CentOS 7: python 2.7 CentOS 8: python 3.6 This make it possible to test and develop on python 2.7 until vdsm is fully functional on python 3, and it save resources in the CI. Thoughts? Nir

3 4

Failed to add fedora-29 host to oVirt
by Eyal Shenitzky 12 Jun '19

12 Jun '19

Hi, I am trying to add fedora-29 host to me oVirt setup and failed due to the following error (from the engine log): 2019-06-11 11:24:59,123+03 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) [73c7d83d] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An error has occurred during installation of Host fedora_29: DNF Problem: conflicting requests - package ovirt-host-4.4.0-0.0.master.20190610132028.git410e453.fc29.x86_64 requires ovirt-hosted-engine-setup, but none of the providers can be installed - package ovirt-host-4.4.0-0.0.master.20190610131544.git410e453.fc29.s390x does not have a compatible architecture - nothing provides ovirt-host-dependencies = 4.4.0-0.0.master.20190610131544.git410e453.fc29 needed by ovirt-host-4.4.0-0.0.master.20190610131544.git410e453.fc29.s390x - nothing provides ovirt-hosted-engine-ha >= 2.4 needed by ovirt-hosted-engine-setup-2.4.0-0.0.master.20190606085519.gitf8402ad.fc29.noarch - nothing provides vdsm-python >= 4.30 needed by ovirt-hosted-engine-setup-2.4.0-0.0.master.20190606085519.gitf8402ad.fc29.noarch - nothing provides ovirt-hosted-engine-ha >= 2.4 needed by ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch - nothing provides glusterfs-cli >= 5.6 needed by ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch - nothing provides vdsm-python >= 4.40.0 needed by ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch. 2019-06-11 11:24:59,133+03 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) [73c7d83d] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An error has occurred during installation of Host fedora_29: Failed to execute stage 'Package installation': Problem: conflicting requests - package ovirt-host-4.4.0-0.0.master.20190610132028.git410e453.fc29.x86_64 requires ovirt-hosted-engine-setup, but none of the providers can be installed - package ovirt-host-4.4.0-0.0.master.20190610131544.git410e453.fc29.s390x does not have a compatible architecture - nothing provides ovirt-host-dependencies = 4.4.0-0.0.master.20190610131544.git410e453.fc29 needed by ovirt-host-4.4.0-0.0.master.20190610131544.git410e453.fc29.s390x - nothing provides ovirt-hosted-engine-ha >= 2.4 needed by ovirt-hosted-engine-setup-2.4.0-0.0.master.20190606085519.gitf8402ad.fc29.noarch - nothing provides vdsm-python >= 4.30 needed by ovirt-hosted-engine-setup-2.4.0-0.0.master.20190606085519.gitf8402ad.fc29.noarch - nothing provides ovirt-hosted-engine-ha >= 2.4 needed by ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch - nothing provides glusterfs-cli >= 5.6 needed by ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch - nothing provides vdsm-python >= 4.40.0 needed by ovirt-hosted-engine-setup-2.4.0-0.0.master.20190610121403.gitb2ee866.fc29.noarch. When I try to install VDSM manually before adding the host the setup it installed the following version: vdsm-4.18.999-447.git0bb7717.fc28.x86_64 Any suggestions? -- Regards, Eyal Shenitzky

2 3