March 2019 - Devel - oVirt List Archives

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

11 Jan '24

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

3 5

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

02 Apr '21

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

6 11

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

07 Aug '19

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

7 10

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

29 Apr '19

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

8 31

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

10 Apr '19

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

5 12

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

02 Apr '19

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

8 17

How write OpenID Connect clients
by du_hongyu＠yeah.net 31 Mar '19

31 Mar '19

hi， I write a OpenID Connect clients follow https://github.com/cqcmdwym/passport-oidc-example https://bugzilla.redhat.com/show_bug.cgi?id=1416491 I fixed passport.use('oidc', new OidcStrategy({ issuer: 'https://10.110.128.120:443/ovirt-engine/sso/openid', authorizationURL: 'https://10.110.128.120:443/ovirt-engine/sso/openid/authorize', tokenURL: 'https://10.110.128.120:443/ovirt-engine/sso/openid/token', userInfoURL: 'https://10.110.128.120:443/ovirt-engine/sso/openid/userinfo', clientID: 'openid-test', clientSecret: '34bACHKj8VN1WOImGUKphzE4fPk3WPvAaKlQFsrQ79g', callbackURL: 'http://10.110.128.195:3000/authorization-code/callback', scope: 'openid ovirt-app-portal ovirt-app-admin ovirt-app-api ovirt-ext=token:password-access ovirt-ext=auth:sequence-priority ovirt-ext=token:login-on-behalf ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search ovirt-ext=token-info:validate ovirt-ext=revoke:revoke-all' error： id token not issued by correct OpenID provider - expected: https://10.110.128.120:443/ovirt-engine/sso/openid | from: https://10.110.128.120:443 Error: id token not issued by correct OpenID provider - expected: https://10.110.128.120:443/ovirt-engine/sso/openid | from: https://10.110.128.120:443 at /home/duhy/workSpace/nodejs/duhy/passport-oidc-example/node_modules/passport-openidconnect/lib/strategy.js:113:62 at /home/duhy/workSpace/nodejs/duhy/passport-oidc-example/node_modules/oauth/lib/oauth2.js:209:7 at passBackControl (/home/duhy/workSpace/nodejs/duhy/passport-oidc-example/node_modules/oauth/lib/oauth2.js:134:9) at IncomingMessage.<anonymous> (/home/duhy/workSpace/nodejs/duhy/passport-oidc-example/node_modules/oauth/lib/oauth2.js:157:7) at IncomingMessage.emit (events.js:194:15) at endReadableNT (_stream_readable.js:1125:12) at process._tickCallback (internal/process/next_tick.js:63:19) Regards Hongyu Du

1 0

Failed to restart vdsmd due to kdump.service
by Eyal Shenitzky 31 Mar '19

31 Mar '19

Hi, Does someone ever encountered on failure to restart vdsmd due to the following issue: # journalctl -xe Mar 28 14:46:46 dhcp-0-221.tlv.redhat.com kdumpctl[8926]: kexec: failed to load kdump kernel Mar 28 14:46:46 dhcp-0-221.tlv.redhat.com kdumpctl[8926]: Starting kdump: [FAILED] Mar 28 14:46:46 dhcp-0-221.tlv.redhat.com systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE Mar 28 14:46:46 dhcp-0-221.tlv.redhat.com systemd[1]: kdump.service: Failed with result 'exit-code'. Mar 28 14:46:46 dhcp-0-221.tlv.redhat.com systemd[1]: Failed to start Crash recovery kernel arming. -- Subject: Unit kdump.service has failed -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit kdump.service has failed. -- -- The result is failed. Mar 28 14:46:46 dhcp-0-221.tlv.redhat.com audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kdump comm="systemd" exe="/usr/lib/systemd/systemd" > Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com sudo[9143]: root : problem with defaults entries ; TTY=pts/0 ; PWD=/root/git/qemu/build ; USER=root ; Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com audit[9143]: USER_ACCT pid=9143 uid=0 auid=0 ses=1 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="root" exe="/usr/b> Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com sudo[9143]: root : TTY=pts/0 ; PWD=/root/git/qemu/build ; USER=root ; COMMAND=/usr/bin/chcon --reference=/usr/bin/qemu-xxx /u> Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com audit[9143]: USER_CMD pid=9143 uid=0 auid=0 ses=1 msg='cwd="/root/git/qemu/build" cmd=6368636F6E202D2D7265666572656E63653D2F75737> Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com audit[9143]: CRED_REFR pid=9143 uid=0 auid=0 ses=1 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sud> Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com sudo[9143]: pam_systemd(sudo:session): Cannot create session: Already running in a session Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com sudo[9143]: pam_unix(sudo:session): session opened for user root by root(uid=0) Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com audit[9143]: USER_START pid=9143 uid=0 auid=0 ses=1 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limi> Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com sudo[9143]: pam_unix(sudo:session): session closed for user root Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com audit[9143]: USER_END pid=9143 uid=0 auid=0 ses=1 msg='op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limit> Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com audit[9143]: CRED_DISP pid=9143 uid=0 auid=0 ses=1 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sud> lines 2486-2509/2509 (END) # systemctl status vdsmd.service ● vdsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Thu 2019-03-28 14:46:45 IST; 5min ago Process: 9059 ExecStopPost=/usr/libexec/vdsm/vdsmd_init_common.sh --post-stop (code=exited, status=0/SUCCESS) Process: 9048 ExecStartPre=/usr/libexec/vdsm/vdsmd_init_common.sh --pre-start (code=exited, status=1/FAILURE) Mar 28 14:46:45 dhcp-0-221.tlv.redhat.com systemd[1]: vdsmd.service: Service hold-off time over, scheduling restart. Mar 28 14:46:45 dhcp-0-221.tlv.redhat.com systemd[1]: vdsmd.service: Scheduled restart job, restart counter is at 5. Mar 28 14:46:45 dhcp-0-221.tlv.redhat.com systemd[1]: Stopped Virtual Desktop Server Manager. Mar 28 14:46:45 dhcp-0-221.tlv.redhat.com systemd[1]: vdsmd.service: Start request repeated too quickly. Mar 28 14:46:45 dhcp-0-221.tlv.redhat.com systemd[1]: vdsmd.service: Failed with result 'exit-code'. Mar 28 14:46:45 dhcp-0-221.tlv.redhat.com systemd[1]: Failed to start Virtual Desktop Server Manager. Occurred to me on a Fedora 28 virtual machine that runs on rhel 7.6 host. Thanks -- Regards, Eyal Shenitzky

3 3

[Ovirt] [CQ weekly status] [29-03-2019]
by Dafna Ron 29 Mar '19

29 Mar '19

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-4.2*: GREEN (#1) Last CQ job failure on 4.2 was 25-03-2019 on project ovirt-ansible-hosted-engine-setup due missing polkit package. *CQ-4.3*: RED (#1) failures in 4.3 and master this week were caused by two issues: 1. we have had random failures on 4 different tests which we are working on debugging with Marcin, Martin and several more people. this has been disruptive this week but did not cause any delays as I was re-triggering failed projects to insure they have their packages buit in tested. Currently we suspect api issue or changes to poastgres are causing the failures 2. we had libcgroup-tools package missing which cause failures for all projects in initialize engine. I merged a patch to fix the issue and provide the package. *CQ-Master:* RED (#1) We have had the same issues as in 4.3 this week. 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

OST: add_master_storage_domain failed, Could not find hosts that are up in DC test-dc
by Yedidyah Bar David 28 Mar '19

28 Mar '19

Hi all, I want to verify [1]. So I ran the manual job, basic suite 4.3 [2]. It failed [3] with $subject. Right before that, verify_add_hosts did succeed, and took 59 seconds. I gave a brief look at the code of verify_add_hosts, and it checks that at least one host is UP. The patch [1] *might* have caused ansible-host-deploy to take longer, still not sure. In any case, ansible-host-deploy finished at 05:48:45 [5], 14 seconds before verify_add_hosts finished at 09:48:59 [4]. Can it be, that a host is considered UP (from the POV of verify_add_hosts), but is still not ready for creating storage? Also, host-1, at the point when OST was killed and collected logs, was right after finishing host-deploy, and didn't start ansible-host-deploy yet, according to engine.log. But host-0 should have been enough, I think. Thanks, [1] https://gerrit.ovirt.org/99000 [2] https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… [3] https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… [4] https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… [5] https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… -- Didi

3 3

planned Jenkins restart
by Evgheni Dereveanchin 28 Mar '19

28 Mar '19

Hi everyone, I'll be performing a planned Jenkins restart within the next hour. No new jobs will be scheduled during this maintenance period. I will inform you once it is over. -- Regards, Evgheni Dereveanchin

1 1

Question regarding support of incremental backups in 4.3.?
by Anton E 27 Mar '19

27 Mar '19

Hi everyone, I'm quite confusing regarding Incremental backups support in 4.3. Could you please clarify it for me. The REST API contains a /backups link in links section of a VM, also the UI allows to enable incremental backup for a disk. However, the /backups returns empty result for any VM. It looks like it is a stump for future development, is that correct? Thanks in advance. Regards, Anton.

3 3

Question regarding support of incremental backups in 4.3.2
by Anton E 27 Mar '19

27 Mar '19

Hi, It seems there is an incomplete or missing support for incremental backup in 4.3.2. Need your clarifications in this regard. The API for a VM (/ovirt-engine/api/vms/<vm-id>) shows the links to <vm-id>/backups service. Also there is an option to enable incremental backup for a disk in the user interface. This makes me believe the incremental backups are supported, however accessing the <vm-id>/backups service gives an empty output. Could you please clarify, whether incremental backup feature is supported in 4.3.2 and I'm trying to use it incorrectly or is this service just a stub for now? Many thanks and regards, Anton Erdman.

2 1

[NOTICE] Failing randomly on get_host_hooks with a NullPointerException
by Dafna Ron 26 Mar '19

26 Mar '19

Hi, we are randomly failing on get_host_hooks test for at least 3 weeks. its not a specific branch or project and there are no commonalities that I can see, aside from not being able to communicate with the host. this week its started happening at least once a day (this morning, 2 out of 3 failures were due to that test). This test has been added by Yaniv Kaul over a year ago and he is no longer working on ovirt I think someone else should take ownership of this test and fix it. Please let me know if you are intending to investigate and either fix the failure or fix the test if not I will add a skip to the test, Thanks, Dafna

5 13

the mess with uploading files
by Hetz Ben Hamo 26 Mar '19

26 Mar '19

Hi, Since both export and ISO domain are being deprecated, the only place to upload remains the data domain. This method works, however, it doesn't "look" good. Uploading few ISO files and you won't see any problem. Upload 50-70 files, and the "directory" looks very messy. So, my question, will there be any "structure" then can be created, like "folders" to put those uploaded files? Thanks Hetz

2 1

ovirt-engine has been tagged (ovirt-engine-4.3.3.1)
by Tal Nisan 26 Mar '19

26 Mar '19

1 0

ovirt-engine has been tagged (ovirt-engine-4.3.3)
by Tal Nisan 26 Mar '19

26 Mar '19

1 0

vdsm has been tagged (v4.30.12)
by Milan Zamazal 26 Mar '19

26 Mar '19

1 0

FYI - Many nightly suites, including Network, HE and HC are failing since 2-3 days ago
by Eyal Edri 26 Mar '19

26 Mar '19

Not sure if all the same issue, but seems to failing around the same time: ovirt-system-tests_hc-basic-suite-4.2 1 day 12 hr - #824 12 hr - #825 57 min integ-tests ovirt-system-tests_hc-basic-suite-master 2 days 12 hr - #1043 12 hr - #1045 51 min integ-tests ovirt-system-tests_he-basic-ansible-suite-4.3 N/A 11 hr - #11 24 sec integ-tests ovirt-system-tests_he-basic-ipv6-suite-master N/A 12 hr - #11 10 min integ-tests ovirt-system-tests_he-basic-iscsi-suite-master 2 days 10 hr - #871 10 hr - #873 1 hr 36 min integ-tests ovirt-system-tests_he-basic-suite-master 2 days 11 hr - #1147 11 hr - #1149 1 hr 26 min integ-tests ovirt-system-tests_he-node-ng-suite-master 2 days 12 hr - #727 12 hr - #729 1 hr 54 min integ-tests ovirt-system-tests_network-suite-master 3 days 12 hr - #926 12 hr - #929 45 min integ-tests ovirt-system-tests_openshift-on-ovirt-suite-4.2 3 days 10 hr - #187 10 hr - #190 45 min integ-tests Links to jobs can be found here: https://jenkins.ovirt.org/ -- Eyal edri MANAGER RHV/CNV DevOps EMEA VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

7 13

Lago's local sync repo not available in OST
by Sandro Bonazzola 25 Mar '19

25 Mar '19

Hi, just seen: 2019-03-25 10:41:36,062-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-hostUpdatesChecker-Thread-2) [] EVENT_ID: HOST_AVAILABLE_UPDATES_FAILED(839), Failed to check for available updates on host lago-basic-suite-master-host-1 with message 'Failed to run check-update of host 'lago-basic-suite-master-host-1'. Error: fatal: [lago-basic-suite-master-host-1]: FAILED! => {"changed": false, "msg": " http://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nTrying other mirror.\nhttp:// 192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nTrying other mirror.\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nTrying other mirror.\nhttp:// 192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nTrying other mirror.\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nTrying other mirror.\nhttp:// 192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nTrying other mirror.\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nTrying other mirror.\nhttp:// 192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nTrying other mirror.\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nTrying other mirror.\nhttp:// 192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nTrying other mirror.\n\n\n One of the configured repositories failed (Latest oVirt nightly),\n and yum doesn't have enough cached data to continue. At this point the only\n safe thing yum can do is fail. There are a few ways to work \"fix\" this:\n\n 1. Contact the upstream for the repository and get them to fix the problem.\n\n 2. Reconfigure the baseurl/etc. for the repository, to point to a working\n upstream. This is most often useful if you are using a newer\n distribution release than is supported by the repository (and the\n packages for the previous distribution release still work).\n\n 3. Run the command with the repository temporarily disabled\n yum --disablerepo=alocalsync ...\n\n 4. Disable the repository permanently, so yum won't use it by default. Yum\n will then just ignore the repository until you permanently enable it\n again or use --enablerepo for temporary usage:\n\n yum-config-manager --disable alocalsync\n or\n subscription-manager repos --disable=alocalsync\n\n 5. Configure the failing repository to be skipped, if it is unavailable.\n Note that yum will try to contact the repo. when it runs most commands,\n so will have to try and fail each time (and thus. yum will be be much\n slower). If it is a very temporary problem though, this is often a nice\n compromise:\n\n yum-config-manager --save --setopt=alocalsync.skip_if_unavailable=true\n\nfailure: repodata/repomd.xml from alocalsync: [Errno 256] No more mirrors to try.\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nhttp://192.168.201.1:8585/default/el7/repodata/repomd.xml: [Errno 14] curl#7 - \"Failed connect to 192.168.201.1:8585; Connection refused\"\nCannot upload enabled repos report, is this client registered?\n", "rc": 1, "results": []} while looking at https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/3867/… for https://gerrit.ovirt.org/98862 Can you please have a look? -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

2 3

[OST upgrade suite] Looking for maintainer
by Ales Musil 25 Mar '19

25 Mar '19

Hi, I am not sure who is currently maintainer for the upgrade suite, but please take a look at [1]. This patch is testing the engine upgrade issue with database vm_id and vmt_id in interface table [2]. And at the same time serves as opening patch to put more sophisticated tests into upgrade suite. Thank you. Regards, Ales [1] https://gerrit.ovirt.org/c/98656/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=1547038 -- ALES MUSIL Associate Software Engineer - rhv network Red Hat EMEA <https://www.redhat.com/> amusil(a)redhat.com IM: amusil <https://red.ht/sig>

3 6

[OST][master] hc-basic-suite-master failing on OVF_STORE not ready
by Sandro Bonazzola 25 Mar '19

25 Mar '19

Job is: https://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-master/1054… Logs show: *03:19:46* TASK [ovirt.hosted_engine_setup : Wait for OVF_STORE disk content] **************03:19:47* FAILED - RETRYING: Wait for OVF_STORE disk content (12 retries left).*03:19:58* FAILED - RETRYING: Wait for OVF_STORE disk content (11 retries left).*03:20:09* FAILED - RETRYING: Wait for OVF_STORE disk content (10 retries left).*03:20:19* FAILED - RETRYING: Wait for OVF_STORE disk content (9 retries left).*03:20:30* FAILED - RETRYING: Wait for OVF_STORE disk content (8 retries left).*03:20:41* FAILED - RETRYING: Wait for OVF_STORE disk content (7 retries left).*03:20:52* FAILED - RETRYING: Wait for OVF_STORE disk content (6 retries left).*03:21:03* FAILED - RETRYING: Wait for OVF_STORE disk content (5 retries left).*03:21:14* FAILED - RETRYING: Wait for OVF_STORE disk content (4 retries left).*03:21:25* FAILED - RETRYING: Wait for OVF_STORE disk content (3 retries left).*03:21:36* FAILED - RETRYING: Wait for OVF_STORE disk content (2 retries left).*03:21:46* FAILED - RETRYING: Wait for OVF_STORE disk content (1 retries left).*03:21:57* failed: [localhost] (item={u'image_id': u'7df4f0be-0192-4e8b-bb6d-ee4cfd2a45d0', u'name': u'OVF_STORE', u'id': u'c55ba7d1-10cf-4f71-a9d2-59cf4ccb08e1'}) => {"attempts": 12, "changed": true, "cmd": "vdsm-client Image prepare storagepoolID=b9c1cfba-4ea2-11e9-b48c-00163e24d363 storagedomainID=a35d1e26-790d-4da6-90d1-df654cbfc0f3 imageID=c55ba7d1-10cf-4f71-a9d2-59cf4ccb08e1 volumeID=7df4f0be-0192-4e8b-bb6d-ee4cfd2a45d0 | grep path | awk '{ print $2 }' | xargs -I{} sudo -u vdsm dd if={} | tar -tvf - 5f87c4b6-2141-4d0c-8ce6-8bb1da97aeb6.ovf", "delta": "0:00:00.578484", "end": "2019-03-24 22:21:57.660496", "item": {"id": "c55ba7d1-10cf-4f71-a9d2-59cf4ccb08e1", "image_id": "7df4f0be-0192-4e8b-bb6d-ee4cfd2a45d0", "name": "OVF_STORE"}, "msg": "non-zero return code", "rc": 2, "start": "2019-03-24 22:21:57.082012", "stderr": "tar: 5f87c4b6-2141-4d0c-8ce6-8bb1da97aeb6.ovf: Not found in archive\ntar: Exiting with failure status due to previous errors\n20+0 records in\n20+0 records out\n10240 bytes (10 kB) copied, 0.00214885 s, 4.8 MB/s", "stderr_lines": ["tar: 5f87c4b6-2141-4d0c-8ce6-8bb1da97aeb6.ovf: Not found in archive", "tar: Exiting with failure status due to previous errors", "20+0 records in", "20+0 records out", "10240 bytes (10 kB) copied, 0.00214885 s, 4.8 MB/s"], "stdout": "", "stdout_lines": []} -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 1

[Ovirt] [CQ weekly status] [22-03-2019]
by Dafna Ron 22 Mar '19

22 Mar '19

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-4.2*: GREEN (#1) Last CQ job failure on 4.2 was 21-03-2019 on project ovirt-hosted-engine-setup due to access to repo centos-cr-el7 in mirrors. this can be solved by projects setting their repo list to work with CI local mirrors. *CQ-4.3*: RED (#1) vdsm is failing on 4.3 due to failure in add_master_storage_domain. this issue is currently investigated by Marcin Sobczyk *CQ-Master:* RED (#1) we are failing on project ovirt-engine for test hotplug_cpu. this was debugged by Evgheni and myself to determine that the issue is indeed in ovirt and not in infra. The test is failing as the internal vm is not responding and we cannot ssh to vm0. *There is a random failure for test get_host_hooks. * It fails on all branches and I can see a NPE in the engine log. The test owner was Yaniv Kaul and Marcin Sobczyk is now looking into the failure. I created a skiptest patch but I am hoping that this would be resolved soon so we do not have to use it. 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

virtual floppy disk bug
by Hetz Ben Hamo 22 Mar '19

22 Mar '19

Hi, Since the ISO domain is being deprecated, it seems that when uploading a VFD to the data domain, it won't show when trying to select it in either VM configuration or Run Once windows. Which component on bugzilla should I report this bug into? Thanks

2 1

where is the vdsm-hook-nestedvt package?
by Hetz Ben Hamo 22 Mar '19

22 Mar '19

Hi, I'm testing the master branch and looking here <https://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/x86_64/> it seems the package vdsm-hook-nestedvt is missing.. Thanks

1 2

Is only master branch of ovirt-engine analyzed on coverity scan?
by simtiaz＠ncsu.edu 21 Mar '19

21 Mar '19

I see the github project ovirt-engine (https://github.com/oVirt/ovirt-engine) is registered on Coverity Scan for routine analysis (https://scan.coverity.com/projects/ovirt-engine?tab=project_settings) My question is - 1) do we only build and analyze the master branch on Coverity? 1a) If yes, why do we not analyze the other branches?

3 3

Usage of ntpdate in OST suites
by Sandro Bonazzola 21 Mar '19

21 Mar '19

Hi, just noticed today we are calling "ntpdate -4 <engine fqdn>" within OST suites but then it fails with "ntpdate: command not found" and we ignore it. I think "chronyc -4 makestep" should be used instead after having configure the engine as server. Any insight on this? -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

2 1

Is only master branch of ovirt-engine analyzed on coverity scan?
by simtiaz＠ncsu.edu 20 Mar '19

20 Mar '19

I see the github project ovirt-engine (https://github.com/oVirt/ovirt-engine) is registered on Coverity Scan for routine analysis (https://scan.coverity.com/projects/ovirt-engine?tab=project_settings) My question is - 1) do we only build and analyze the master branch on Coverity? 1a) If yes, why do we not analyze the other branches? 1b) If no, how to detect which alert on coverity is for which branch? Thanks, Nasif

1 0

ovirt-jboss-modules-maven-plugin package
by Sandro Bonazzola 20 Mar '19

20 Mar '19

Hi, just noticed today we are building on master a package named ovirt-jboss-modules-maven-plugin. The package is not required by any other package at spec file / rpm level and it has never been shipped in an official release as far as I can tell. Grep says we are using a java package through maven called ovirt-jboss-modules-maven-plugin in: - ovirt-engine - ovirt-engine-api-metamodel It doesn't seem we are bundling the library so it looks like a build time dependency only. Am I correct? Why aren't we adding it as BuildRequires to ovirt-engine spec file and keeping downloading it from maven central at every build instead of using system installed library? Thanks, -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

2 3

Increase limits on concurrent https://jenkins.ovirt.org/job/standard-manual-runner/ jobs
by Nir Soffer 20 Mar '19

20 Mar '19

We started to use this job to build artifacts for running OST. Looks like this job is limited to one concurrent job, which make it less useful than it could be. If we don't make it easy to run OST, people will not run it, and the change queue will break. Please change the limit to use the same limit used for regular builds. We seem to be able to create more then 10 concurrent builds by uploading patches to gerrit. The manual runner should this as well. Nir

1 0

Check-Merged Fails for ovirt-provider-ovn
by Anton Marchukov 20 Mar '19

20 Mar '19

Hello. I note that check-merged for ovirt-provider-ovn [1] fails on the following: > assert len(networks) == 1 E AssertionError: assert 2 == 1 E + where 2 = len([{'id': 'e0e73fc4-88e1-41e4-91c9-c9519c02f319', 'mtu': 1442, 'name': 'net1', 'port_security_enabled': False, ...}, {'id': '34d40d1f-b2e3-4eb9-9202-6d311162ea5a', 'mtu': 1442, 'name': 'ls0', 'port_security_enabled': False, ...}]) test_provider_api.py:72: AssertionError seems like the unit tests are failing. This is not OST failure itself, but it happens right before that on the build stage and hence this project fails in the Change Queue, so we need to check it. [1] https://jenkins.ovirt.org/job/ovirt-provider-ovn_standard-on-merge/263/ Anton. -- Anton Marchukov Associate Manager - RHV DevOps - Red Hat

5 14

ovirt-vdsmfake
by Sandro Bonazzola 20 Mar '19

20 Mar '19

Hi, on master we have ovirt-vdsmfake package. Is there any reason for branching it and/or add it to 4.3 pipeline? -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

4 7

oVirt Orb 4.3.2 build failure importing image
by Sandro Bonazzola 20 Mar '19

20 Mar '19

Hi, I was trying to build oVirt Orb with 4.3.2 GA content and it failed with: 2019-03-20 13:53:13,210::utils.py::_ret_via_queue::62::lago.utils::DEBUG::Error while running thread Thread-11 Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/lago/utils.py", line 57, in _ret_via_queue queue.put({'return': func()}) File "/home/jenkins/workspace/ovirt-demo-tool_4.3_check-patch-el7-x86_64/ovirt-demo-tool/deploy/sdk_scripts/deploy/002_bootstrap.py", line 875, in import_non_template_from_glance generic_import_from_glance(prefix) File "/home/jenkins/workspace/ovirt-demo-tool_4.3_check-patch-el7-x86_64/ovirt-demo-tool/deploy/sdk_scripts/deploy/002_bootstrap.py", line 711, in generic_import_from_glance target_image.import_image(import_action) AttributeError: 'NoneType' object has no attribute 'import_image' Lago log is here: https://jenkins.ovirt.org/job/ovirt-demo-tool_4.3_check-patch-el7-x86_64/15… If I understood it correctly, it's importing an image from glance to export domain, but if I remember correctly, export domains are deprecated in 4.3 so no reason to do this here. Any insight? -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

2 1

How to debug engine backend code
by du_hongyu＠yeah.net 20 Mar '19

20 Mar '19

hi I can step through frontend code follow https://www.ovirt.org/blog/2017/08/ovirt-webadmin-gwt-debug-quick-refresh.h…, I want to step through backend code, now I only print log to debug backend code, But i do not how to debug backend code by other method , can you give me some advise? Regards Hongyu Du

2 1

Re: Cannot add fedora 28 host to oVirt
by Eyal Shenitzky 20 Mar '19

20 Mar '19

Added devel On Wed, Mar 20, 2019 at 9:05 AM Yedidyah Bar David <didi(a)redhat.com> wrote: > On Tue, Mar 19, 2019 at 3:49 PM Eyal Shenitzky <eshenitz(a)redhat.com> > wrote: > > > > Hi, > > > > I tried to add Fedora 28 host to ovirt and failed due to missing > ovirt-host-deploy: > > > > 2019-03-19 14:27:34,795+02 ERROR > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > (VdsDeploy) [1ce188c7] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An > error has occurred during installation of Host 10.35.1.234: Internal > error: No module named ovirt_host_deploy. > > 2019-03-19 14:27:34,823+02 ERROR > [org.ovirt.engine.core.uutils.ssh.SSHDialog] > (EE-ManagedThreadFactory-engine-Thread-2355) [1ce188c7] SSH error running > command root(a)10.35.1.234:'umask 0077; MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" > mktemp -d -t ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > > /dev/null 2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; tar > --warning=no-timestamp -C "${MYTMP}" -x && "${MYTMP}"/ovirt-host-deploy > DIALOG/dialect=str:machine DIALOG/customization=bool:True': IOException: > Command returned failure code 2 during SSH session 'root(a)10.35.1.234' > > 2019-03-19 14:27:34,824+02 ERROR > [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (VdsDeploy) [1ce188c7] > Error during deploy dialog > > 2019-03-19 14:27:34,838+02 ERROR > [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] > (EE-ManagedThreadFactory-engine-Thread-2355) [1ce188c7] Error during host > 10.35.1.234 install > > > > When I tried to install ovirt-host-deploy on the Fedora 28 machine I > failed because otopi was missing. > > > > Do we have a known issue for Fedora 28 host? > > Nothing that I can currently recall, although it's been some time since I > tried. > > The missing ovirt_host_deploy/otopi are not something you should > install on the host. They are included in the bundle. > > Where is the engine (OS)? Is it current master? dev-env or RPM? Which > otopi/ovirt-host-deploy you have there? Current master, both? > The engine is also on Fedora 28, this is the current master (dev-env) host-deploy: python2-ovirt-host-deploy-1.8.0-0.0.master.20181016080559.gitff6ea7d.fc28.noarch ovirt-host-deploy -common-1.8.0-0.0.master.20181016080559.gitff6ea7d.fc28.noarch otopi: python2-otopi-1.8.0-0.0.master.20181017100341.git487c83a.fc28.noarch python3-otopi-1.8.0-0.0.master.20181017100341.git487c83a.fc28.noarch otopi-common-1.8.0-0.0.master.20181017100341.git487c83a.fc28.noarch > > Please check/share content of the bundle. After you try 'Add host', it > should be in > /var/cache/ovirt-engine/ovirt-host-deploy.tar/var/cache/ovirt-engine/ovirt-host-deploy.tar > . It's > auto-generated, so you can remove it and try again. > What should I look for there? > Also, IMO you can open such threads on devel(a)ovirt.org.il. > > Best regards, > -- > Didi > -- Regards, Eyal Shenitzky

2 4

dwh failing on master, perhaps because engine is 4.4
by Yedidyah Bar David 20 Mar '19

20 Mar '19

Hi all, https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… fails with: ... lambda: engine.service('ovirt-engine-dwhd').alive() File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 282, in assert_true_within_short assert_equals_within_short(func, True, allowed_exceptions) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 266, in assert_equals_within_short func, value, SHORT_TIMEOUT, allowed_exceptions=allowed_exceptions File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 252, in assert_equals_within '%s != %s after %s seconds' % (res, value, timeout) 'False != True after 180 seconds dwhd log has: 2019-03-20 03:07:06|5iRyfJ|KapTFh|KapTFh|OVIRT_ENGINE_DWH|MinimalVersionCheck|Default|5|tDie|tDie_1|2019-03-20 03:07:06|You have upgraded your oVirt Engine and now require an upgrade of the ovirt-engine-dwh package. Please run engine-setup to upgrade the version. Service will now exit.|4 I assume that this is because the engine is now 4.4 and dwh master is still 4.3. I see that dwh already branched 4.3, should we bump master to 4.4? Thanks and best regards, -- Didi

1 0

Re: OST failures (Update to use gluster 5)
by Sahina Bose 20 Mar '19

20 Mar '19

On Wed, Mar 20, 2019 at 12:31 AM Greg Sheremeta <gshereme(a)redhat.com> wrote: > Hey, > > Is someone looking at all the OST failures? > he, hc, and network are all failing with the 409 error. Started after the > merge of > "Update to use gluster 5" > I'm not positive that's the problem, but seems likely. > > Do you mean https://gerrit.ovirt.org/#/c/98470/ ? this should have affected only the hc-master suite Both hc and he suites are failing with this error..this is probably not related to gluster, as he suite does not use gluster. Adding Simone and devel ml for insights "tar: ebaaaefb-5d8c-4059-a59e-b81cdb09e001.ovf: Not found in archive\ntar: Exiting with failure status due to previous errors\n20+0 records in\n20+0 records out\n10240 bytes (10 kB) copied, 0.00144612 s, 7.1 MB/s", "stderr_lines": ["tar: ebaaaefb-5d8c-4059-a59e-b81cdb09e001.ovf: Not found in archive" > Best wishes, > Greg > > -- > > GREG SHEREMETA > > SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX > > Red Hat NA > > <https://www.redhat.com/> > > gshereme(a)redhat.com IRC: gshereme > <https://red.ht/sig> >

2 3

oVirt Engine 4.3 has been branched
by Tal Nisan 19 Mar '19

19 Mar '19

Which means that if you want your content in Engine 4.3.3 and onwards you should backport to the ovirt-engine-4.3 branch, master now basically serves as the future branch (4.4)

2 1

Are we ready to branch ovirt-engine for 4.3?
by Sandro Bonazzola 18 Mar '19

18 Mar '19

Hi, we built 4.3.2 RC2 this week and we have a planned GA for it next week. Since branching engine requires a bit of coordination, are we ready to branch it? 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>

3 8

Missed ovirt-openshift-extensions release?
by Sandro Bonazzola 18 Mar '19

18 Mar '19

Hi, just seen https://twitter.com/RealGophersShip/status/1105791600762986496 Are we missing a release of ovirt-openshift-extensions? It wasn't included in 4.3.2 RC2 Thanks, -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

2 7

oci: command line tool for oVirt CI
by Nir Soffer 18 Mar '19

18 Mar '19

I want to share a nice little tool that can make your life easier. https://github.com/nirs/oci With this PR: https://github.com/nirs/oci/pull/1 You will be able to do this: $ python system-tests.py 98535 2019-03-15 21:17:04,579 INFO [system-tests] [ 1/8 ] Getting build info for change 98535 2019-03-15 21:17:05,295 INFO [system-tests] [ 2/8 ] Starting build-artifacts job for {'url': u'git://gerrit.ovirt.org/vdsm', 'ref': u'refs/changes/35/98535/3'} 2019-03-15 21:17:06,134 INFO [system-tests] [ 3/8 ] Waiting for queue item https://jenkins.ovirt.org/queue/item/382806/ 2019-03-15 21:17:07,960 INFO [system-tests] [ 4/8 ] Waiting for job http://jenkins.ovirt.org/job/standard-manual-runner/89/ 2019-03-15 21:26:21,381 INFO [system-tests] [ 5/8 ] Starting oVirt system tests basic suite with custom repos http://jenkins.ovirt.org/job/standard-manual-runner/89/ 2019-03-15 21:26:22,242 INFO [system-tests] [ 6/8 ] Waiting for queue item https://jenkins.ovirt.org/queue/item/382817/ 2019-03-15 21:30:43,558 INFO [system-tests] [ 7/8 ] Waiting for job http://jenkins.ovirt.org/job/ovirt-system-tests_manual/4330/ 2019-03-15 22:10:52,891 INFO [system-tests] [ 8/8 ] System tests completed with SUCCESS Yes, one command from your favorite shell. It takes about 53 minutes, but on Fedora you get notifications when commands finish. No need to to add "ci please build" comment, wait until the job is complete, copy the job url, open OST page, wait (jenkins is slow), paste the build artifacts url, start the job, wait, wait more, check if OST is done, (not yet), wait more..., OST finished, check the logs, did you paste the wrong url? The tool is not finished yet. If you like to contribute to this fun little project please check the issues: https://github.com/nirs/oci/issues Most of the issues are easy. Some harder like: - https://github.com/nirs/oci/issues/11 - https://github.com/nirs/oci/issues/12 Feel free to open new issues if you have an idea for this tool. Nir

5 5

Dependencies issue on manual OST
by Eyal Shenitzky 18 Mar '19

18 Mar '19

Hi, I encounter this dependency issue while trying to run OST manually: https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4343/ *09:49:35* @ Deploy oVirt environment: *09:49:35* # Deploy environment: *09:49:35* * [Thread-2] Deploy VM lago-basic-suite-master-host-0: *09:49:35* * [Thread-3] Deploy VM lago-basic-suite-master-host-1: *09:49:35* * [Thread-4] Deploy VM lago-basic-suite-master-engine: *09:49:54* * [Thread-3] Deploy VM lago-basic-suite-master-host-1: Success (in 0:00:18) *09:49:56* STDERR*09:49:56* + yum -y install ovirt-host*09:49:56* Error: Package: ovirt-host-dependencies-4.4.0-0.0.master.20190308162916.git4c2aa13.el7.x86_64 (alocalsync)*09:49:56* Requires: vdsm-client >= 4.40.0*09:49:56* Available: vdsm-client-4.30.11-10.gitf23ba52.el7.noarch (alocalsync)*09:49:56* vdsm-client = 4.30.11-10.gitf23ba52.el7*09:49:56* Error: Package: ovirt-host-dependencies-4.4.0-0.0.master.20190308162916.git4c2aa13.el7.x86_64 (alocalsync)*09:49:56* Requires: vdsm >= 4.40.0*09:49:56* Installing: vdsm-4.30.11-10.gitf23ba52.el7.x86_64 (alocalsync)*09:49:56* vdsm = 4.30.11-10.gitf23ba52.el7*09:49:56* Error: Package: ovirt-host-dependencies-4.4.0-0.0.master.20190308162916.git4c2aa13.el7.x86_64 (alocalsync)*09:49:56* Requires: vdsm-client >= 4.40.0*09:49:56* Installing: vdsm-client-4.30.11-10.gitf23ba52.el7.noarch (alocalsync)*09:49:56* vdsm-client = 4.30.11-10.gitf23ba52.el7 Does someone encounter it? Thanks -- Regards, Eyal Shenitzky

3 3

OST hyperconverged master fails
by Greg Sheremeta 17 Mar '19

17 Mar '19

Hi, I'm trying to run OST hyperconverged master locally, but it's missing some ansible inventory file and fails. Is this a known issue? + lago copy-to-vm lago-hc-basic-suite-master-host-0 /home/greg/projects/ovirt-system-tests/hc-basic-suite-master/generate-hc-answerfile.sh /root/generate-hc-answerfile.sh @ Copy /home/greg/projects/ovirt-system-tests/hc-basic-suite-master/generate-hc-answerfile.sh to lago-hc-basic-suite-master-host-0:/root/generate-hc-answerfile.sh: @ Copy /home/greg/projects/ovirt-system-tests/hc-basic-suite-master/generate-hc-answerfile.sh to lago-hc-basic-suite-master-host-0:/root/generate-hc-answerfile.sh: Success (in 0:00:00) + lago shell lago-hc-basic-suite-master-host-0 /root/exec_playbook.sh lago-hc-basic-suite-master-host-0 lago-hc-basic-suite-master-host-1 lago-hc-basic-suite-master-host-2 */root/exec_playbook.sh: line 9: /usr/share/doc/gluster.ansible/playbooks/hc-ansible-deployment/ohc_gluster_inventory.yml: No such file or directory* + RET_CODE=1 + '[' 1 -ne 0 ']' + echo 'ansible setup on lago-hc-basic-suite-master-host-0 failed with status 1.' ansible setup on lago-hc-basic-suite-master-host-0 failed with status 1. + exit 1 + on_exit + [[ 1 -ne 0 ]] + logger.error 'on_exit: Exiting with a non-zero status' + logger.log ERROR 'on_exit: Exiting with a non-zero status' + set +x 2019-03-15 06:16:36.021775858-0400 run_suite.sh::on_exit::ERROR:: on_exit: Exiting with a non-zero status -- GREG SHEREMETA SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX Red Hat NA <https://www.redhat.com/> gshereme(a)redhat.com IRC: gshereme <https://red.ht/sig>

3 4

[Ovirt] [CQ weekly status] [15-03-2019]
by Dafna Ron 15 Mar '19

15 Mar '19

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-4.2*: GREEN (#1) Last CQ job failure on 4.2 was 14-03-2019 on project v2v-conversion-host due to missing failed build artifacts which was fixed the same day. *CQ-4.3*: RED (#1) Last job to failed today. it had 13 changes and CQ is still bisecting the result. *CQ-Master:* RED (#1) Last failure was today due to a build-artifacts failure. a message was sent to patch owner. Current running jobs for 4.2 [1] and master [2] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.2_change-qu… [2] 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

Re: [URGENT] stop merging to vdsm master
by Sandro Bonazzola 13 Mar '19

13 Mar '19

Adding missing devel list. Il giorno mar 12 mar 2019 alle ore 10:24 Dafna Ron <dron(a)redhat.com> ha scritto: > Hi, > > We have been continuously failing CQ on the vdsm project since 07-03-2019. > > The latest failure is still in vm migration test and root cause is still > pointing to: > > https://gerrit.ovirt.org/#/c/97381/22 - virt: In FIPS mode, use SASL auth > instead of qemu passwords > > Please stop merging until issue is resolved as we are risking further > regressions being merged. > > Thanks, > Dafna > > -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

5 6

[hyperv] hvinfo: command line tool to get the HyperV enlightements status from within the guest
by Francesco Romani 12 Mar '19

12 Mar '19

Hi all, lately I've been involved again in hyperv support. I was tasked to help improve the testability of the hyperv guest configuration. Hyperv support is a set of optimizations that libvirt/qemu offer to improve the runtime behaviour (stability, performance) of Windows guets. See for example: https://libvirt.org/formatdomain.html#elementsFeatures oVirt does support them (see for example https://github.com/oVirt/vdsm/blob/master/lib/vdsm/virt/libvirtxml.py#L243) and will keep supporting them because they are a key feature for windows guests. Up until now the easiest (only?) way to check if a hyperv optmization was really enabled was to inspect the libvirt XML and/or the QEMU command line flags But we wanted to have another check. Enter hvinfo: https://github.com/fromanirh/hvinfo hvinfo is a simple tool that decodes CPUID informations according to the publicly-available HyperV specs (https://github.com/MicrosoftDocs/Virtualization-Documentation/tree/live/tlfs) and report what the guest sees. It takes no arguments - just run it!-, it requires no special privileges and emits easy to consume JSON. It is designed to help and integrate into fully automated CI/QA. Being a commandline tool, is hard to give a "screenshot", so let me just report sample output (admin privileges not actually required) Windows PowerShell Copyright (C) Microsoft Corporation. All rights reserved. PS C:\Users\admin> cd .\Downloads\ PS C:\Users\admin\Downloads> .\hvinfo.exe { "HyperVsupport": true, "Features": { "GuestDebugging": false, "PerformanceMonitor": false, "PCPUDynamicPartitioningEvents": true, "HypercallInputParamsXMM": false, "VirtualGuestIdleState": false, "HypervisorSleepState": false, "NUMADistanceQuery": false, "TimerFrequenciesQuery": false, "SytheticMCEInjection": false, "GuestCrashMSR": false, "DebugMSR": false, "NPIEP": false, "DisableHypervisorAvailable": false, "ExtendedGvaRangesForFlushVirtualAddressList": false, "HypercallOutputReturnXMM": false, "SintPollingMode": false, "HypercallMsrLock": false, "UseDirectSyntheticTimers": false }, "Recommendations": { "HypercallAddressSpaceSwitch": false, "HypercallLocalTLBFlush": false, "HypercallRemoteTLBFlush": false, "MSRAPICRegisters": true, "MSRSystemReset": false, "RelaxedTiming": true, "DMARemapping": false, "InterruptRemapping": false, "X2APICMSR": false, "DeprecatingAutoEOI": false, "SyntheticClusterIPI": false, "ExProcessorMasks": false, "Nested": false, "INTForMBECSyscalls": false, "NestedEVMCS": false, "SyncedTimeline": false, "DirectLocalFlushEntire": false, "NoNonArchitecturalCoreSharing": false, "SpinlockRetries": 8191 } } PS C:\Users\admin\Downloads> Caveat: the name of the features are the same of the spec, so we need mappings for oVirt flags, libvirt flags and so on. For example libvirt xml domain.features.hyperv.relaxed[state="on"] maps to hvinfo json Features.Recommendations.RelaxedTiming=true Feel free to test it and report any issue Bests, -- Francesco Romani Senior SW Eng., Virtualization R&D Red Hat IRC: fromani github: @fromanirh

2 1

ovirt-engine has been tagged (ovirt-engine-4.3.2.1)
by Tal Nisan 12 Mar '19

12 Mar '19

1 0

vdsm has been tagged (v4.30.11)
by Milan Zamazal 11 Mar '19

11 Mar '19

3 3

unboundid-ldapsdk-4.0.10 is now available for testing
by Sandro Bonazzola 11 Mar '19

11 Mar '19

On Fedora 28 we have 4.0.7. On Fedora 30 we had 4.0.9. The new releases 4.0.10 will be soon available within repositories for Fedora >= 30 and includes several bug fixes and enhancements. You can see release notes for 4.0.10 here: https://github.com/pingidentity/ldapsdk/releases In oVirt this package is required by ovirt-engine-extension-aaa-ldap. If you're going to test the package, please provide karma at https://bodhi.fedoraproject.org/updates/unboundid-ldapsdk-4.0.10-1.fc30 Martin, Ravi, let me know if you see value in backporting this version to Fedora 28 and EL7 for oVirt 4.3 consumption. Thanks, -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0

[ OST Failure Report ] [ oVirt 4.3 (vdsm-jsonrpc-java) ] [ 10-3-19 ] [ Upgrade Suite ]
by Liora Milbaum 11 Mar '19

11 Mar '19

Link and headline of suspected patches: Link to Job: http://jenkins.ovirt.org/job/ovirt-4.3_change-queue-tester/153/ Link to all logs: (Relevant) error snippet from the log: <error> [36m # 001_upgrade_engine.test_initialize_engine: [0m [0m [0m [36m * Copy /home/jenkins/workspace/ovirt-4.3_change-queue-tester/ovirt-system-tests/upgrade-from-prevrelease-suite-4.3/upgrade-engine-answer-file.conf to lago-upgrade-from-prevrelease-suite-4-3-engine:/tmp/answer-file-post: [0m [0m [0m [36m * Copy /home/jenkins/workspace/ovirt-4.3_change-queue-tester/ovirt-system-tests/upgrade-from-prevrelease-suite-4.3/upgrade-engine-answer-file.conf to lago-upgrade-from-prevrelease-suite-4-3-engine:/tmp/answer-file-post: [32mSuccess [0m (in 0:00:00) [0m [36m * Collect artifacts: [0m [0m [0m [36m ~ [Thread-8] Copy from lago-upgrade-from-prevrelease-suite-4-3-engine:/tmp/otopi* to /dev/shm/ost/deployment-upgrade-from-prevrelease-suite-4.3/default/test_logs/001_upgrade_engine.test_initialize_engine-20190307160642/lago-upgrade-from-prevrelease-suite-4-3-engine/_tmp_otopi*: [31mERROR [0m (in 0:00:00) [0m [36m - [Thread-8] lago-upgrade-from-prevrelease-suite-4-3-engine: [31mERROR [0m (in 0:00:00) [0m [36m * Collect artifacts: [31mERROR [0m (in 0:00:01) [0m [36m # 001_upgrade_engine.test_initialize_engine: [31mERROR [0m (in 0:00:49) [0m [36m # Results located at /dev/shm/ost/deployment-upgrade-from-prevrelease-suite-4.3/001_upgrade_engine.py.junit.xml [0m [36m@ Run test: 001_upgrade_engine.py: [31mERROR [0m (in 0:00:49) [0m [31mError occured, aborting Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 383, in do_run self.cli_plugins[args.ovirtverb].do_run(args) File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 184, in do_run self._do_run(**vars(args)) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 549, in wrapper return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 560, in wrapper return func(*args, prefix=prefix, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 107, in do_ovirt_runtest raise RuntimeError('Some tests failed') RuntimeError: Some tests failed [0m </error> -- *Liora Milbaum* Senior Principal Software Engineer RHV/CNV DevOps EMEA VIRTUALIZATION R&D T: +972-54-6560051 <https://red.ht/sig>

3 2

[ OST Failure Report ] [ oVirt master (ovirt-engine) ] [ 10-03-19 ] [ verify_glance_import ]
by Liora Milbaum 10 Mar '19

10 Mar '19

Link and headline of suspected patches: Link to Job: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13310/ Link to all logs: (Relevant) error snippet from the log: <error> [36m@ Run test: 004_basic_sanity.py: [0m [0m [0m nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] [36m # verify_glance_import: [0m [0m [0m [31m * Unhandled exception in <function <lambda> at 0x7f9f147cbed8> Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 234, in assert_equals_within res = func() File "/home/jenkins/workspace/ovirt-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/004_basic_sanity.py", line 1153, in <lambda> lambda: api.disks.get(disk_name).status.state == 'ok', AttributeError: 'NoneType' object has no attribute 'status' [0m [36m * Collect artifacts: [0m [0m [0m [36m ~ [Thread-4] Copy from lago-basic-suite-master-engine:/tmp/otopi* to /dev/shm/ost/deployment-basic-suite-master/default/test_logs/004_basic_sanity.verify_glance_import-20190307161910/lago-basic-suite-master-engine/_tmp_otopi*: [31mERROR [0m (in 0:00:00) [0m [36m - [Thread-4] lago-basic-suite-master-engine: [31mERROR [0m (in 0:00:00) [0m [36m * Collect artifacts: [31mERROR [0m (in 0:00:02) [0m [36m # verify_glance_import: [31mERROR [0m (in 0:00:02) [0m [36m # Results located at /dev/shm/ost/deployment-basic-suite-master/004_basic_sanity.py.junit.xml [0m [36m@ Run test: 004_basic_sanity.py: [31mERROR [0m (in 0:00:02) [0m [31mError occured, aborting Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 383, in do_run self.cli_plugins[args.ovirtverb].do_run(args) File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 184, in do_run self._do_run(**vars(args)) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 549, in wrapper return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 560, in wrapper return func(*args, prefix=prefix, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 107, in do_ovirt_runtest raise RuntimeError('Some tests failed') RuntimeError: Some tests failed [0m </error> -- *Liora Milbaum* Senior Principal Software Engineer RHV/CNV DevOps EMEA VIRTUALIZATION R&D T: +972-54-6560051 <https://red.ht/sig>

2 1

[ OST Failure Report ] [ oVirt Master (ovirt-engine-nodejs-modules) ] [ 27-02-2019 ] [ 002_bootstrap.add_vm2_lease ]
by Dafna Ron 10 Mar '19

10 Mar '19

Hi, We have a failure on the project in basic suite, master branch. The recent failure was in patch: https://gerrit.ovirt.org/#/c/98087/1 - Add pre-seed for ovirt-web-ui CQ is pointing at the below as the root cause (which was merged a while back): https://gerrit.ovirt.org/#/c/97491/ - Add pre-seed for ovirt-web-ui Can you please check the issue as it seems both patches are changing the same thing and the project seem to be broken since https://gerrit.ovirt.org/#/c/97491/3 Latest failure: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13171/ Logs: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13171/artifa… errors from logs: Engine: 2019-02-27 13:37:28,479-05 ERROR [org.ovirt.engine.core.bll.UpdateVmCommand] (default task-1) [74283e25] Transaction rolled-back for command 'org.ovirt.engine.core.bll.UpdateVmCommand'. 2019-02-27 13:37:28,483-05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-1) [74283e25] EVENT_ID: USER_FAILED_UPDATE_VM(58), Failed to update VM vm2 (User: admin@inter nal-authz). 2019-02-27 13:37:28,485-05 INFO [org.ovirt.engine.core.bll.UpdateVmCommand] (default task-1) [74283e25] Lock freed to object 'EngineLock:{exclusiveLocks='[vm2=VM_NAME]', sharedLocks='[3500eb82-e5e2-4e24-b41c-ea 02d9f6adee=VM]'}' 2019-02-27 13:37:28,485-05 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-1) [74283e25] method: runAction, params: [UpdateVm, VmManagementParametersBase:{commandId='340 59769-05b9-429e-8356-f6b9b9953f55', user='admin', commandType='UpdateVm', vmId='3500eb82-e5e2-4e24-b41c-ea02d9f6adee'}], timeElapsed: 6618ms 2019-02-27 13:37:28,486-05 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-1) [] Operation Failed: [] 2019-02-27 13:37:28,579-05 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (EE-ManagedThreadFactory-engineScheduled-Thread-85) [] method: get, params: [e29c0ba1-464c-4eb4-a8f2-c6933d9 9969a], timeElapsed: 3ms vdsm: 2019-02-27 13:37:21,987-0500 INFO (jsonrpc/1) [vdsm.api] FINISH lease_info error=No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee from=::ffff:192.168.201.4,43920, flow_id=117dec74-ad59-4b12-8148-b2c130337c10, task_id=9c297d41-0aa7-4c74-b268-b710e666bc6c (api:52) 2019-02-27 13:37:21,988-0500 ERROR (jsonrpc/1) [storage.TaskManager.Task] (Task='9c297d41-0aa7-4c74-b268-b710e666bc6c') Unexpected error (task:875) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in _run return fn(*args, **kargs) File "<string>", line 2, in lease_info File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 50, in method ret = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 3702, in lease_info info = dom.lease_info(lease.lease_id) File "/usr/lib/python2.7/site-packages/vdsm/storage/sd.py", line 674, in lease_info return vol.lookup(lease_id) File "/usr/lib/python2.7/site-packages/vdsm/storage/xlease.py", line 553, in lookup raise NoSuchLease(lease_id) NoSuchLease: No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee 2019-02-27 13:37:21,988-0500 INFO (jsonrpc/1) [storage.TaskManager.Task] (Task='9c297d41-0aa7-4c74-b268-b710e666bc6c') aborting: Task is aborted: u'No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee' - code 100 (task:1181) 2019-02-27 13:37:21,988-0500 ERROR (jsonrpc/1) [storage.Dispatcher] FINISH lease_info error=No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee (dispatcher:87) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/dispatcher.py", line 74, in wrapper result = ctask.prepare(func, *args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 108, in wrapper return m(self, *a, **kw) File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 1189, in prepare raise self.error NoSuchLease: No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee

5 9

ovirt-vmconsole-1.0.6-3.fc28.noarch: Non-fatal POSTUN scriptlet failure
by Nir Soffer 10 Mar '19

10 Mar '19

When updating Fedora 28 host with ovirt-release-master repo, I see this error: Running scriptlet: ovirt-vmconsole-1.0.6-3.fc28.noarch 143/251 libsemanage.semanage_module_key_set_name: Name /usr/share/selinux/packages/ovirt-vmconsole/ovirt_vmconsole.pp is invalid. semodule: Failed on /usr/share/selinux/packages/ovirt-vmconsole/ovirt_vmconsole.pp! warning: %postun(ovirt-vmconsole-1.0.6-3.fc28.noarch) scriptlet failed, exit status 1 Non-fatal POSTUN scriptlet failure in rpm package ovirt-vmconsole Non-fatal POSTUN scriptlet failure in rpm package ovirt-vmconsole I did not try to use it, I don't know if we have a real issue. Looks like we need to either fix the issue or silence the warnings. Nir

2 1

[Ovirt] [CQ weekly status] [08-03-2019]
by Dafna Ron 09 Mar '19

09 Mar '19

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-4.2*: GREEN (#1) Last CQ job failure on 4.2 was 06-03-2019 on project ovirt-ansible-vm-infra due to missing jtk2 package. this issue is now fixed with patch: https://gerrit.ovirt.org/#/c/98304/ *CQ-4.3*: RED (#1) Last job to fail is for project imgbased. the failure is due to the random failures we have been having from test add_vm2_lease. this issue is currently debated in the list. New repo and packages were updated by Galit due to failure in CQ for missing packages: https://gerrit.ovirt.org/#/c/98312/ *CQ-Master:* RED (#1) We were failing this week due to missing packages which was fixed by: https://gerrit.ovirt.org/#/c/98304/ We also had two regressions which were fixed by: https://gerrit.ovirt.org/#/c/98317/ and by https://gerrit.ovirt.org/#/c/98371/ All projects are currently passing Current running jobs for 4.2 [1] and master [2] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.2_change-qu… [2] 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 1

ovirt and AMD virtualization bug
by Hetz Ben Hamo 09 Mar '19

09 Mar '19

Hi, I've done some research on a bug which I found on the AMD Zen/Zen+ based CPU's. Apparently, when using nested virtualization, the CPU doesn't expose the "monitor" CPU flag. While other virtualization solutions (Xen, ESXi, Hyper-V) don't care about this issue and let you run with nested without any problem, oVirt doesn't let you launch or create any VM and it complains that this "monitor" CPU flag is missing. Since QEMU/KVM cannot do anything about it, I was wondering if the ovirt dev team could ignore this flag please. Thanks

2 1

[VDSM] build-artifacts on s390x broken again (bad mock/dnf cache?)
by Nir Soffer 09 Mar '19

09 Mar '19

build-artifacts on s390x fail now with: [Errno 2] No such file or directory: '/var/cache/dnf/updates-07b7057ee4fded96/packages/systemd-238-12.git07f8cd5.fc28.s390x.rpm' Here are few example failures: https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa… https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa… This is going to block the change queue when we merge these patches, and we have 4.3 build soon. We had this issue few week ago, and Barak fixed this by deleting caches on the slaves. I hope this can be fixed quickly this time. Nir

1 0

ovirt-optimizer: subproject health check
by Sandro Bonazzola 08 Mar '19

08 Mar '19

Hi, oVirt Optimizer has been introduced in oVirt 3.5.2 back in 2014. Last update on master branch is dated November 2017 with version 0.15 The package has been shipped till oVirt 4.2.8 and it has not been shipped in oVirt 4.3 despite no official deprecation has been announced. According to Gerrit, current maintainers are Doron Fediuck and Martin Sivak. According to Bugzilla there is one bug open since February 2018: Bug 1545077 <https://bugzilla.redhat.com/show_bug.cgi?id=1545077> - cancel optimization button is enabled all the time which is currently untargeted, unassigned and without activity since March 2018. The project has feature / development documentation at https://ovirt.org/develop/release-management/features/sla/optaplanner.html but no official documentation. Can we declare this subproject retired from oVirt project and drop CI automation for it? Thanks, -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0

ovirt-scheduler-proxy: subproject health check
by Sandro Bonazzola 08 Mar '19

08 Mar '19

Hi, oVirt Scheduler Proxy has been introduced in oVirt 3.3.1 back in 2013. Last update on master branch is dated November 2017 with 0.1.8 released. The package has been shipped till oVirt 4.2.8 and it has not been shipped in oVirt 4.3 despite no official deprecation has been announced. According to Gerrit, current maintainers are Doron Fediuck and Martin Sivak. According to Bugzilla there are no open bugs or RFEs for this project. The project has no documentation available on oVirt website. Can we declare this subproject retired from oVirt project and drop CI automation for it? Thanks, -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

2 2

[ci test tool] how to start build-artifacts job using jenkins API?
by Nir Soffer 08 Mar '19

08 Mar '19

I'm trying to a write a tool that given a gerrit patch number, will: 1. Start build artifacts job (instead of adding "ci please build" comment)\ 2. Wait until the job is complete 3. Start OST with CUSTOM_REPOS using the build artifacts job from step 1 4. Wait until OST complets 5. Post a comment with the OST link to gerrit So testing patches will easy as: $ ci test 12345 Building rpms... Starting OST... OST succeeded, congratulations! I can start OST and watch it, but I could not find a way to start vdsm build-artifacts job. This starts a job: curl -i \ --user USERNAME:API_TOKEN \ -X POST \ https://jenkins.ovirt.org/job/vdsm_standard-check-patch/build But the fail quickly in the first "detecting" stage. https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa… Clicking "Build Now" button on the job page fails in the same way. And this: curl -i \ --user USERNAME:API_TOKEN \ -X POST \ https://jenkins.ovirt.org/job/vdsm_standard-check-patch/buildWithParameters Fails with 500 Internal server error, with a huge traceback, hiding this expected message: java.lang.IllegalStateException: This build is not parameterized! Looks like the job need to be parametrized: - https://jenkins.ovirt.org/job/vdsm_standard-check-patch/configure - https://jenkins.ovirt.org/job/ovirt-system-tests_manual/configure I guess we can workaround this by posting "ci please build" comment on gerrit using gerrit API, and then waiting waiting an grabbing the build link from the comment added by jenkins, but I really don't want to go in this direction. I hope we can have a proper solution in the job configuration. Nir

1 1

[ OST Failure Report ] [ oVirt Master ] [ 07-03-2019 ] [ 008_basic_ui_sanity.initialize_firefox]
by Galit Rosenthal 07 Mar '19

07 Mar '19

Hi, we are failing basic suite master (vdsm) Can you please have a look at the issue? *Error Message:* Message: Error forwarding the new session new session request for webdriver should contain a location header or an 'application/json;charset=UTF-8' response body with the session ID. *from the [2]:* *08:22:04* + xmllint --format /dev/shm/ost/deployment-basic-suite-master/008_basic_ui_sanity.py.junit.xml*08:22:04* <?xml version="1.0" encoding="UTF-8"?>*08:22:04* <testsuite name="nosetests" tests="7" errors="1" failures="0" skip="0">*08:22:04* <testcase classname="008_basic_ui_sanity" name="init" time="0.001"/>*08:22:04* <testcase classname="008_basic_ui_sanity" name="start_grid" time="144.413">*08:22:04* <system-out><![CDATA[executing shell: docker ps*08:22:04* CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES*08:22:04* *08:22:04* *08:22:04* executing shell: docker rm -f grid_node_chrome grid_node_firefox selenium-hub*08:22:04* *08:22:04* Error response from daemon: No such container: grid_node_chrome*08:22:04* Error response from daemon: No such container: grid_node_firefox*08:22:04* Error response from daemon: No such container: selenium-hub*08:22:04* *08:22:04* executing shell: docker kill grid_node_chrome grid_node_firefox selenium-hub*08:22:04* *08:22:04* Error response from daemon: Cannot kill container grid_node_chrome: No such container: grid_node_chrome*08:22:04* Error response from daemon: Cannot kill container grid_node_firefox: No such container: grid_node_firefox*08:22:04* Error response from daemon: Cannot kill container selenium-hub: No such container: selenium-hub*08:22:04* *08:22:04* executing shell: docker ps*08:22:04* CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES*08:22:04* *08:22:04* *08:22:04* executing shell: docker network ls*08:22:04* NETWORK ID NAME DRIVER SCOPE*08:22:04* f710c07f46da bridge bridge local*08:22:04* 7d05935c9513 host host local*08:22:04* 415e4fd8022f none null local*08:22:04* *08:22:04* *08:22:04* executing shell: docker network rm grid*08:22:04* *08:22:04* Error response from daemon: network grid not found*08:22:04* *08:22:04* executing shell: docker network ls*08:22:04* NETWORK ID NAME DRIVER SCOPE*08:22:04* f710c07f46da bridge bridge local*08:22:04* 7d05935c9513 host host local*08:22:04* 415e4fd8022f none null local*08:22:04* *08:22:04* *08:22:04* executing shell: docker network ls*08:22:04* NETWORK ID NAME DRIVER SCOPE*08:22:04* f710c07f46da bridge bridge local*08:22:04* 7d05935c9513 host host local*08:22:04* 415e4fd8022f none null local*08:22:04* *08:22:04* *08:22:04* creating docker network for grid*08:22:04* executing shell: docker network create grid*08:22:04* 7406c15c141eccac968e5fba9f091d83831a29c92fc9f61b95bc4fba47f5e73f*08:22:04* *Global link to the CQ fail[3]* [1] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_chang… [2] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_chang… [3] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_chang… -- GALIT ROSENTHAL SOFTWARE ENGINEER Red Hat <https://www.redhat.com/> galit(a)gmail.com T: 972-9-7692230 <https://red.ht/sig>

4 3

[ OST Failure Report ] [ oVirt Master ] [ 07-03-2019 ] [ / 004_basic_sanity.verify_glance_import]
by Galit Rosenthal 07 Mar '19

07 Mar '19

Hi, we are failing basic suite master ( ovirt-engine) It looks a problem in ovirt-engine Can you please have a look at the issue? Thanks, Galit Error [1]: 'NoneType' object has no attribute 'status' -------------------- >> begin captured logging << -------------------- ovirtlago.testlib: ERROR: * Unhandled exception in <function <lambda> at 0x7f5e9feb3ed8> Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 234, in assert_equals_within res = func() File "/home/jenkins/workspace/ovirt-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/004_basic_sanity.py", line 1153, in <lambda> lambda: api.disks.get(disk_name).status.state == 'ok', AttributeError: 'NoneType' object has no attribute 'status' --------------------- >> end captured logging << ------------- US CQ of the ovirt-engine results can be found [2] We see the same error DS as well [3] [1] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_chang… [2] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_chang… [3] https://rhv-devops-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/blue/rest/organi… -- GALIT ROSENTHAL SOFTWARE ENGINEER Red Hat <https://www.redhat.com/> galit(a)gmail.com T: 972-9-7692230 <https://red.ht/sig>

5 9

Please don't remove instance type
by Baptiste Agasse 07 Mar '19

07 Mar '19

Hi all, We are happy oVirt users for some years now (we started with 3.6, now on 4.2) and we manage most of our virtualization stacks with it. To provision and manage our machines, we use the foreman (for bare metal and virtual machines) on top of it. I made some little contributions to the foreman and other underlying stuff to have a deeper integration with oVirt, like to be able to select instance type directly from foreman interface/api and we rely on it. We use instance types to standardize our vms by defining system resources (memory, cpu and cpu topology) console type, boot options. On top of that we plan to use templates to apply OS (CentOS 7 and CentOS 6 actually). Having resources definitions separated from OS installation help us to keep instance types and templates lists small and don't bother users about some technical underlying stuff. As we are interested in automating oVirt maintenance tasks and configuration with ansible, I asked at FOSDEM oVirt booth if there is any ansible module to manage instance types in Ovirt as I didn't find it in ovirt ansible infra repo. The person to whom I asked the question said that you are planning to remove instance types from ovirt, and this make me sad :(. So here I am to ask why do you plan to remove instance types from oVirt. As far as I know, it's fairly common to have "instance types" / "flavors" / "sizes" on one side and then templates (bare OS, preinstalled appliances...) on other side and pick one of each to make an instance. If this first part is missing in future version of ovirt, it will be a pain point for us. So, my question is, do you really plan to remove instances type definitely ? Cheers. -- Baptiste

3 4

Taking down the engine without setting global maintenance
by Yedidyah Bar David 07 Mar '19

07 Mar '19

Hi all, How about making this change: Right before the engine goes down cleanly, it marks the shared storage saying it did not crash but exited cleanly, and then HE-HA will not try to restart it on another host. Perhaps make this optional, so that users can do clean shutdowns and still test HA cleanly (or some other use cases, where users might not want this). This should help a lot cases where people restarted their engine for some reason, e.g. upgrade, and forgot to set maintenance. Makes sense? -- Didi

3 5

How can I set up a newly created virtual machine to use the qcow2 format disk by default
by mask.zan＠gmail.com 06 Mar '19

06 Mar '19

How can I set up a newly created virtual machine to use the qcow2 format disk by default? my ovirt version is 4.3.1

2 1

Which OST suites are run on Jenkins?
by Milan Zamazal 06 Mar '19

06 Mar '19

Hi, where can I find which OST suites are run on Jenkins automatically and when? Thanks, Milan

2 3

getting a weird error when doing OST
by Ahmad Khiet 06 Mar '19

06 Mar '19

Hi, I'm trying to run OST on a patch, but I'm getting the following error: tried twice.. and I'm getting the same error : https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4221/console https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4206/console Thanks, Ahmad. *10:06:27* *10:06:27* - STDERR*10:06:27* ++ uname -r*10:06:27* ++ awk -F. '{print $(NF-1)}'*10:06:27* + DIST=el7*10:06:27* + FC_REGEX='^fc[0-9]+$'*10:06:27* + cat*10:06:27* + cat*10:06:27* ++ ip route*10:06:27* ++ awk '$1=="default" {print $5; exit}'*10:06:27* + NIC=eth0*10:06:27* ++ /sbin/ip -4 -o addr show dev eth0*10:06:27* ++ awk '{split($4,a,"."); print a[1] "." a[2] "." a[3] "." a[4]}'*10:06:27* ++ awk -F/ '{print $1}'*10:06:27* + ADDR=192.168.201.4*10:06:27* + echo '192.168.201.4 engine'*10:06:27* + pkgs_to_install=("ntp" "net-snmp" "ovirt-engine" "ovirt-log-collector" "ovirt-engine-extension-aaa-ldap*" "otopi-debug-plugins" "cronie")*10:06:27* + install_firewalld*10:06:27* + [[ el7 == \e\l\7 ]]*10:06:27* + rpm -q firewalld*10:06:27* + systemctl enable firewalld*10:06:27* + systemctl start firewalld*10:06:27* + [[ el7 == \e\l\7 ]]*10:06:27* + install_cmd='yum install --nogpgcheck --downloaddir=/dev/shm -y'*10:06:27* + yum install --nogpgcheck --downloaddir=/dev/shm -y ntp net-snmp ovirt-engine ovirt-log-collector 'ovirt-engine-extension-aaa-ldap*' otopi-debug-plugins cronie*10:06:27* Error: Package: ovirt-engine-4.3.0-0.2.master.20190303132316.git026851f.el7.noarch (alocalsync)*10:06:27* Requires: rubygem-fluent-plugin-viaq_data_model*10:06:27* Error: Package: ovirt-engine-setup-plugin-ovirt-engine-4.3.0-0.2.master.20190303132316.git026851f.el7.noarch (alocalsync)*10:06:27* Requires: rh-postgresql95-postgresql-contrib*10:06:27* Error: Package: ovirt-engine-4.3.0-0.2.master.20190303132316.git026851f.el7.noarch (alocalsync)*10:06:27* Requires: rubygem-fluent-plugin-rewrite-tag-filter*10:06:27* Error: Package: ovirt-engine-setup-plugin-ovirt-engine-4.3.0-0.2.master.20190303132316.git026851f.el7.noarch (alocalsync)*10:06:27* Requires: rh-postgresql95-postgresql-server*10:06:27* Error: Package: ovirt-engine-4.3.0-0.2.master.20190303132316.git026851f.el7.noarch (alocalsync)*10:06:27* Requires: rubygem-fluent-plugin-secure-forward*10:06:27* Error: Package: ovirt-engine-tools-backup-4.3.0-0.2.master.20190303132316.git026851f.el7.noarch (alocalsync)*10:06:27* Requires: rh-postgresql95-postgresql*10:06:27* Error: Package: ovirt-engine-4.3.0-0.2.master.20190303132316.git026851f.el7.noarch (alocalsync)*10:06:27* Requires: rh-postgresql95-postgresql-server*10:06:27* Error: Package: 1:java-1.8.0-openjdk-1.8.0.201.b09-2.el7_6.x86_64 (alocalsync)*10:06:27* Requires: gtk2(x86-64)*10:06:27* Error: Package: ovirt-engine-4.3.0-0.2.master.20190303132316.git026851f.el7.noarch (alocalsync)*10:06:27* Requires: rh-postgresql95-postgresql-contrib*10:06:27* Error: Package: ovirt-engine-4.3.0-0.2.master.20190303132316.git026851f.el7.noarch (alocalsync)*10:06:27* Requires: rubygem-fluent-plugin-collectd-nest*10:06:27* + ret=1*10:06:27* + echo 'install failed with status 1'*10:06:27* + exit 1*10:06:27* *10:06:27* * [Thread-4] Deploy VM lago-basic-suite-master-engine: ERROR (in 0:00:19)*10:07:41* * [Thread-2] Deploy VM lago-basic-suite-master-host-0: ERROR (in 0:01:34)*10:07:41* # Deploy environment: ERROR (in 0:01:34)*10:07:41* @ Deploy oVirt environment: ERROR (in 0:01:34)*10:07:41* Error occured, aborting*10:07:41* Traceback (most recent call last):*10:07:41* File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 383, in do_run*10:07:41* self.cli_plugins[args.ovirtverb].do_run(args)*10:07:41* File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 184, in do_run*10:07:41* self._do_run(**vars(args))*10:07:41* File "/usr/lib/python2.7/site-packages/lago/utils.py", line 549, in wrapper*10:07:41* return func(*args, **kwargs)*10:07:41* File "/usr/lib/python2.7/site-packages/lago/utils.py", line 560, in wrapper*10:07:41* return func(*args, prefix=prefix, **kwargs)*10:07:41* File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 181, in do_deploy*10:07:41* prefix.deploy()*10:07:41* File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, in wrapper*10:07:41* return func(*args, **kwargs)*10:07:41* File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line 127, in wrapper*10:07:41* return func(*args, **kwargs)*10:07:41* File "/usr/lib/python2.7/site-packages/ovirtlago/prefix.py", line 284, in deploy*10:07:41* return super(OvirtPrefix, self).deploy()*10:07:41* File "/usr/lib/python2.7/site-packages/lago/sdk_utils.py", line 50, in wrapped*10:07:41* return func(*args, **kwargs)*10:07:41* File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, in wrapper*10:07:41* return func(*args, **kwargs)*10:07:41* File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 1671, in deploy*10:07:41* self.virt_env.get_vms().values()*10:07:41* File "/usr/lib/python2.7/site-packages/lago/utils.py", line 103, in invoke_in_parallel*10:07:41* return vt.join_all()*10:07:41* File "/usr/lib/python2.7/site-packages/lago/utils.py", line 57, in _ret_via_queue*10:07:41* queue.put({'return': func()})*10:07:41* File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 1662, in _deploy_host*10:07:41* host.name(),*10:07:41* LagoDeployError: /dev/shm/ost/deployment-basic-suite-master/default/scripts/_home_jenkins_workspace_ovirt-system-tests_manual_ovirt-system-tests_basic-suite-master_deploy-scripts_setup_engine.sh failed with status 1 on lago-basic-suite-master-engine

2 1

oVirt documentation vs. feature pages
by Greg Sheremeta 05 Mar '19

05 Mar '19

Hi, TL;DR: please don't direct users to feature pages -- direct them to end-user documentation instead. And maintain content separation between end-user documentation and technical docs like feature pages. ... Lately we've cleaned up documentation on ovirt.org, and I wanted to share some of my thoughts about it. As a user experience focused person, I really believe that clear and helpful documentation is crucial to the project's success. I've also seen outdated documentation be a source of extreme frustration for our users. In the distant past, most of oVirt's documentation was written by developers on a wiki, typically in the form of "feature pages." Feature pages are basically technical design documents with occasionally some user help sprinkled in. With oVirt 4.0, we put a great set of clear documentation, written by technical writers, on the oVirt website (which was also converted from a wiki to a regular static site). This documentation is up to date with 4.2, and we'll get the 4.3 content out there soon. This official documentation lives at https://ovirt.org/documentation and it should be considered the authoritative place for users to access our documentation. Feature pages, on the other hand, are (now) for developers. When you hear the term "feature page", think "technical design document." Most users should not be interested in this content. It helps to think about the personas. 1. oVirt admins -- the person who sets up oVirt on Day 1 and 2. This is the person who cares about and will read the Installation Guide and the Administration Guide. These live under /documentation, e.g. https://ovirt.org/documentation/install-guide/Installation_Guide.html 2. oVirt users -- the people who use oVirt to create, manage, and use virtual machines, etc. This person will care about and read the VM Portal Guide, User Guides, and such. These also live under /documentation, e.g. https://ovirt.org/documentation/vmm-guide/Virtual_Machine_Management_Guide.… 3. Developers -- you and I, and occasionally highly curious and technical admins. These people might care about how the project works under the hood -- high level designs, code flows, etc. Persona 2, oVirt users, do not care about these details when they are learning to use oVirt, so end-user documentation should not be polluted with this type of content. This content now lives exclusively under /develop, the developer's section of the site. https://ovirt.org/develop/release-management/features/ Let's help our users by directing them to the end-user documentation, not to feature pages. If you would like to contribute end-user documentation, it should go under /documentation and not in a feature page. If you build a new feature, the technical stuff goes under /develop/release-management/features/ and the end-user stuff goes under /documentation. Feedback welcome :) Best wishes, Greg -- GREG SHEREMETA SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX Red Hat NA <https://www.redhat.com/> gshereme(a)redhat.com IRC: gshereme <https://red.ht/sig>

4 5

[URGENT] gluster-anisble dependency disappeared from copr repository
by Sandro Bonazzola 05 Mar '19

05 Mar '19

Hi, with https://gerrit.ovirt.org/#/c/97730/ a dependency on gluster-ansible package from sac/gluster-ansible copr repository has been introduced. Such package is not available anymore causing breakage at oVirt Node build time. Please fix gluster ansible packaging as soon as possible for properly handling upgrade for those who already installed gluster-ansible and fix the requirements for oVirt node builds. Thanks -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

2 3

Updating Fedora 28 fail with "Package glusterfs-5.4-1.fc28.x86_64.rpm is not signed"
by Nir Soffer 05 Mar '19

05 Mar '19

# dnf update ... Package glusterfs-5.4-1.fc28.x86_64.rpm is not signed Package glusterfs-libs-5.4-1.fc28.x86_64.rpm is not signed Package glusterfs-server-5.4-1.fc28.x86_64.rpm is not signed Package glusterfs-fuse-5.4-1.fc28.x86_64.rpm is not signed Package glusterfs-devel-5.4-1.fc28.x86_64.rpm is not signed Package glusterfs-api-devel-5.4-1.fc28.x86_64.rpm is not signed Package glusterfs-api-5.4-1.fc28.x86_64.rpm is not signed Package glusterfs-cli-5.4-1.fc28.x86_64.rpm is not signed Package glusterfs-client-xlators-5.4-1.fc28.x86_64.rpm is not signed Package glusterfs-extra-xlators-5.4-1.fc28.x86_64.rpm is not signed Package python3-gluster-5.4-1.fc28.x86_64.rpm is not signed The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: GPG check FAILED This is a development laptop and I never installed or need glusterfs-server. I could remove glusterfs-server, but other glusterfs packages seems to be required by libvirt, libguestfs and qemu. I tried "dnf clean all" and removed yum/dnf caches, but it does not help. In the meantime I could update by excluding glusterfs. I hope someone has a better solution. Nir

2 2

Re: [JIRA] (OVIRT-2566) make network suite blocking
by Nir Soffer 04 Mar '19

04 Mar '19

On Mon, Nov 5, 2018 at 8:59 AM danken (oVirt JIRA) < jira(a)ovirt-jira.atlassian.net> wrote: > danken created OVIRT-2566: > ----------------------------- > > Summary: make network suite blocking > Key: OVIRT-2566 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2566 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: OST > Reporter: danken > Assignee: infra > Priority: High > > > The network suite is executing nightly for almost a year. It has a caring > team that tends to it, and it does not have false positives. > Currently, it currently fails for a week on the 4.2 branch, but it is due > to a production code bug. > > https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… > > I would like to see this suite escalated to the importance of the basic > suite, making it a gating condition for marking a collection of packages as > "tested". > I'm ok with this only if it will gate *only* vdsm-network package, and it will run in parallel, so it does not slow down OST run. For basic suite, we have too many random failures, so I don't think it is useful, and we should make it optional. Nir > > [~gbenhaim(a)redhat.com] what should be done to make this happen? > > > > > -- > This message was sent by Atlassian Jira > (v1001.0.0-SNAPSHOT#100095) > _______________________________________________ > Infra mailing list -- infra(a)ovirt.org > To unsubscribe send an email to infra-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/infra@ovirt.org/message/VFQ776FLS2QBA… >

1 0

ovirt-engine has been tagged (ovirt-engine-4.3.2)
by Tal Nisan 04 Mar '19

04 Mar '19

1 0

vdsm has been tagged (v4.30.10)
by Milan Zamazal 04 Mar '19

04 Mar '19

1 0

vdsm Check-patch failed - ERROR: Error fetching remote repo 'origin'
by Eyal Shenitzky 04 Mar '19

04 Mar '19

Hey, I saw the following error on the vdsm check-patch: *09:47:31* ERROR: Error fetching remote repo 'origin'*09:47:31* hudson.plugins.git.GitException: Failed to fetch from https://gerrit.ovirt.org/vdsm*09:47:31* at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:904)*09:47:31* at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1144)*09:47:31* at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1175)*09:47:31* at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:120)*09:47:31* at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:90)*09:47:31* at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:77)*09:47:31* at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)*09:47:31* at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)*09:47:31* at java.util.concurrent.FutureTask.run(FutureTask.java:266)*09:47:31* at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)*09:47:31* at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)*09:47:31* at java.lang.Thread.run(Thread.java:748)*09:47:31* Caused by: hudson.plugins.git.GitException: Command "git clean -fdx" returned status code 1:*09:47:31* stdout: *09:47:31* stderr: warning: failed to remove .tox/lib-py27/lib/python2.7/site-packages/pytest_cov/__pycache__/plugin.cpython-27-PYTEST.pyc: Permission denied*09:47:31* warning: failed to remove .tox/lib-py27/lib/python2.7/site-packages/pytest_cov/__pycache__/compat.cpython-27-PYTEST.pyc: Permission denied*09:47:31* warning: failed to remove .tox/lib-py27/lib/python2.7/site-packages/pytest_cov/__pycache__/engine.cpython-27-PYTEST.pyc: Permission denied*09:47:31* warning: failed to remove .tox/lib-py27/lib/python2.7/site-packages/pytest_cov/__pycache__/embed.cpython-27-PYTEST.pyc: Permission denied*09:47:31* warning: failed to remove tests/__pycache__/pywatch_test.cpython-27-PYTEST.pyc: Permission denied*09:47:31* warning: failed to remove tests/__pycache__/prlimit_test.cpython-27-PYTEST.pyc: Permission denied*09:47:31* warning: failed to remove tests/__pycache__/ssl_test.cpython-27-PYTEST.pyc: Permission denied*09:47:31* warning: failed to remove tests/__pycache__/hooking_test.cpython-27-PYTEST.pyc: Permission denied*09:47:31* warning: failed to remove tests/common/__pycache__/systemd_test.cpython-27-PYTEST.pyc: Permission denied*09:47:31* warning: failed to remove tests/common/__pycache__/systemctl_test.cpython-27-PYTEST.pyc: Permission denied*09:47:31* warning: failed to remove tests/common/__pycache__/commands_test.cpython-27-PYTEST.pyc: Permission denied*09:47:31* Does someone encounter it? -- Regards, Eyal Shenitzky

2 4

Can't discover luns on iscisi target when host is running fedora 28
by Fedor Gavrilov 04 Mar '19

04 Mar '19

Hi, Recently I hit an issue when I can't add iscsi storage domain because engine can't see any LUNs there. I wonder if I missed some step in the configuration or something. There is a fedora 29 machine running iscsi target which has a single lun and host (banana) registered in its ACL: [cucumber@cucumber ~]$ sudo targetcli [sudo] password for cucumber: targetcli shell version 2.1.fb48 Copyright 2011-2013 by Datera, Inc and others. For help on commands, type 'help'. /iscsi/iqn.20...e:target/tpg1> ls o- tpg1 ..................................................................................................... [no-gen-acls, no-auth] o- acls ................................................................................................................ [ACLs: 1] | o- iqn.1994-05.com.redhat:4bf5ff1a15b6 ........................................................................ [Mapped LUNs: 1] | o- mapped_lun0 ................................................................................. [lun0 fileio/filestore0 (rw)] o- luns ................................................................................................................ [LUNs: 1] | o- lun0 ................................................................... [fileio/filestore0 (/etc/fileio) (default_tg_pt_gp)] o- portals .......................................................................................................... [Portals: 1] o- 0.0.0.0:3260 ........................................................................................................... [OK] From fedora 28 host I can login and logout, but there is this segfault and when I try getting LUN info it fails: [banana@banana ~]$ sudo iscsiadm --mode discovery --type sendtargets --portal cucumber 192.168.111.4:3260,1 iqn.2016-01.com.example:target [banana@banana ~]$ sudo iscsiadm -m node -T iqn.2016-01.com.example:target -l Logging in to [iface: default, target: iqn.2016-01.com.example:target, portal: 192.168.111.4,3260] (multiple) Login to [iface: default, target: iqn.2016-01.com.example:target, portal: 192.168.111.4,3260] successful. [banana@banana ~]$ sudo iscsiadm -m session -P 3 -r 2 iscsiadm: could not read session targetname: 5 iscsiadm: Could not get session info for sid 2 [banana@banana ~]$ sudo iscsiadm -m session -P 3 iSCSI Transport Class version 2.0-870 version 6.2.0.874 Segmentation fault It seems I am hitting this: https://bugzilla.redhat.com/show_bug.cgi?id=1462767 Could this be the reason that there are no LUNs in engine web UI after I discover iscsi target? Is anyone aware of workaround or whether I am doing something wrong? Thanks, Fedor Gavrilov

2 2

v2v_conversion_host jenkins job bugged
by Sandro Bonazzola 02 Mar '19

02 Mar '19

Hi, just noticed today we have a jenkins job: https://jenkins.ovirt.org/job/oVirt_v2v-conversion-host_standard-on-ghpush/… which generates packages named like: v2v-conversion-host-1.11.0-0.oVirt_v2v_conversion_host_standard_on.githpush_13.20190301133957.fc27.src.rpm v2v-conversion-host-1.11.0.tar.gz v2v-conversion-host-ansible-1.11.0-0.oVirt_v2v_conversion_host_standard_on.githpush_13.20190301133957.fc27.noarch.rpm v2v-conversion-host-debugsource-1.11.0-0.oVirt_v2v_conversion_host_standard_on.githpush_13.20190301133957.fc27.x86_64.rpm v2v-conversion-host-provider-1.11.0-0.oVirt_v2v_conversion_host_standard_on.githpush_13.20190301133957.fc27.x86_64.rpm v2v-conversion-host-provider-debuginfo-1.11.0-0.oVirt_v2v_conversion_host_standard_on.githpush_13.20190301133957.fc27.x86_64.rpm v2v-conversion-host-wrapper-1.11.0-0.oVirt_v2v_conversion_host_standard_on.githpush_13.20190301133957.fc27.noarch.rpm which are breaking NVR naming conventions for RPMs and are probably the result of a bug within jenkins job. Please fix the job as soon as possible and clean up - https://resources.ovirt.org/repos/ovirt/tested/master - https://resources.ovirt.org/repos/ovirt/tested/4.2 - https://resources.ovirt.org/pub/ovirt-4.2-snapshot - https://resources.ovirt.org/pub/ovirt-master-snapshot Thanks, -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

2 1

Re: [Vdo-devel] impact of --emulate512 setting for VDO volumes
by Guillaume Pavese 02 Mar '19

02 Mar '19

Thank you very much for your answer. I am copying ovirt-devel too as that could be of interest to them. Guillaume Pavese Ingénieur Système et Réseau Interactiv-Group On Sat, Mar 2, 2019 at 7:00 AM Michael Sclafani <sclafani(a)redhat.com> wrote: > Hi! > > 512 emulation was intended to support drivers that only do a fraction of > their I/O in blocks smaller 4KB. It is not optimized for performance in any > way. Under the covers, VDO is still operating on 4KB physical blocks, so > each 512-byte read is potentially amplified to a 4KB read, and each > 512-byte write to a 4KB read followed by a 4KB write. A workload consisting > exclusively of 512-byte randomly-distributed writes could effectively be > amplified by a factor of 16. > > We have a suite of automated tests we run in 512e mode on a nightly basis. > That suite is a subset of our regular tests, containing only ones we expect > would be likely to expose problems specific to the emulation. > > There should be no penalty to having emulation enabled on a volume that no > longer uses it. If the I/O is 4KB-aligned and 4KB or larger, having it > enabled won't affect it. > It does not appear the setting can be modified by the VDO manager, but I > cannot remember at this moment why that should be so. > > Hope this helps. > > On Fri, Mar 1, 2019 at 2:24 PM Guillaume Pavese < > guillaume.pavese(a)interactiv-group.com> wrote: > >> Hello, >> >> We are planning to deploy VDO with oVirt 4.3 on centos 7.6 (on SSD >> devices). >> As oVirt does not support 4K devices yet, VDO volumes are created with >> the parameter "--emulate512 enabled" >> >> What are the implications of this setting? Does it impact performance? If >> so, is it IOPS or throughput that is impacted? What about reliability (is >> that mode equally tested as standard mode)? >> >> As I saw on RH Bugzilla, support for 4K devices in oVirt will need to >> wait at least for Centos 7.7 >> Once that is supported, would it be possible to transition/upgrade an >> emulate512 vdo volume to a standard one? >> >> Thanks, >> >> Guillaume Pavese >> Ingénieur Système et Réseau >> Interactiv-Group >> _______________________________________________ >> Vdo-devel mailing list >> Vdo-devel(a)redhat.com >> https://www.redhat.com/mailman/listinfo/vdo-devel >> >

1 0

[RHV] [CQ weekly status] [01-03-2019]
by Dafna Ron 01 Mar '19

01 Mar '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-RHV-4.2:* GREEN (#1) Last failure was on 28-02-2019 for project rhevm-appliance due to a failed build-artifacts job. this issue is still happening and message was sent to developer. *CQ-RHV-Master:* GREEN (#1) Last failure is identical to 4.2 - build-artifacts for the same project. ** We do not yet have a 4.3 CQ job which we will start working on next week. Current running jobs for 4.2 [1] and for master [2] can be found below: [1] https://rhv-devops-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Change%20qu… [2] https://rhv-devops-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Change%20qu… 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)

1 0

[Ovirt] [CQ weekly status] [01-03-2019]
by Dafna Ron 01 Mar '19

01 Mar '19

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-4.2*: GREEN (#1) Last CQ job failure on 4.2 was 27-02-2019 on project ovirt-provider-ovn due to a failed build-artifacts job. this issue is now fixed. Please note that this is a CQ job failure but not an OST job failure as we exit if no package is available. *CQ-4.3*: RED (#1) We added a CQ job for 4.3 but not all projects created the branch yet. I created a google sheet to follow the advancement of this work and I will use this report to ask all the managers to go over the doc and add info: https://docs.google.com/spreadsheets/d/1i142cTN_0QwOvogtlQiF6bcIYxTpBqYBed2… *CQ-Master:* RED (#1) We have sporadic failures in test get_host_devices this is effecting all projects and we have yet to know what is causing the issue. Michal checked the issue and thinks the test should be modified to do a re-try as the info is filled by the host 4 seconds after the query is sent. Milan was asked to add a loop with 1s delay to get_host_devices to fix the test. Please note that we have ruled out a possible infra cause for this failure before alerting dev as the failure is sporadic and happens on multiple projects. Jira: https://ovirt-jira.atlassian.net/browse/OVIRT-2686 Current running jobs for 4.2 [1] and master [2] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.2_change-qu… [2] 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

[ OST Failure Report ] [ oVirt Master ] [ 27-02-2019 ] [ 002_bootstrap.get_host_devices]
by Galit Rosenthal 01 Mar '19

01 Mar '19

Hi, we are failing basic suite master (vdsm, ovirt-engine-sdk ...) It happens sporadically. We disqualify that this is an infra issue. Can you please have a look at the issue? ERROR: <testcase classname="002_bootstrap" name="get_host_devices" time="0.077"> <error type="exceptions.RuntimeError" message="*Could not find block_vda_1 device in host devices*: "><![CDATA[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-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py", line 1016, in get_host_devices raise RuntimeError('Could not find block_vda_1 device in host devices: {}'.format(device_list)) RuntimeError: Could not find block_vda_1 device in host devices: ]]></error> Thanks, Galit Examples, Full logs: [1] https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/ovirt-m… [2] https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/ovirt-m… _______________________________________________ Infra mailing list -- infra(a)ovirt.org To unsubscribe send an email to infra-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/infra@ovirt.org/message/WXW6II3NYEXHI… -- GALIT ROSENTHAL SOFTWARE ENGINEER Red Hat <https://www.redhat.com/> galit(a)gmail.com T: 972-9-7692230 <https://red.ht/sig>

9 14

unboundid-ldapsdk-4.0.9 is now available for testing
by Sandro Bonazzola 01 Mar '19

01 Mar '19

On Fedora we had previously 4.0.7. The new releases 4.0.7 will be soon available within repositories for Fedora >= 30 and includes several bug fixes and enhancements. You can see release notes for 4.0.8 and 4.0.9 here: https://github.com/pingidentity/ldapsdk/releases In oVirt this package is required by ovirt-engine-extension-aaa-ldap. If you're going to test the package, please provide feedback here. Martin, Ravi, let me know if you see value in backporting this version to Fedora 28 and EL7 for oVirt 4.3 consumption. Thanks, -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0

[NOTICE] infra issue in progress in jenkins
by Dafna Ron 01 Mar '19

01 Mar '19

Hi, We had a job fail due to a failure in yum. it seems yum is searching for repodata in a wrong location. Evgheni is currently working to investigate and fix the problem and will update soon Jira opened: https://ovirt-jira.atlassian.net/browse/OVIRT-2689 Thanks, Dafna

1 1