July 2019 - Devel - oVirt List Archives

Jenkins build fails to clone gerrit repo
by Vojtech Juranek 21 Jul '19

21 Jul '19

Hi, lots of Jenkin jobs fail as they cannot fetch git repo from gerrit: 17:35:32 Fetching upstream changes from https://gerrit.ovirt.org/vdsm 17:35:32 > git --version # timeout=10 17:35:32 > git fetch --tags --progress https://gerrit.ovirt.org/vdsm +refs/heads/*:refs/remotes/origin/* 17:36:38 ERROR: Error cloning remote repo 'origin' 17:36:38 hudson.plugins.git.GitException: Command "git fetch --tags --progress https://gerrit.ovirt.org/vdsm +refs/heads/*:refs/remotes/origin/*" returned status code 128: 17:36:38 stdout: 17:36:38 stderr: error: RPC failed; result=22, HTTP code = 502 17:36:38 fatal: The remote end hung up unexpectedly see e.g. [1, 2, 3] for more details, to name couple of examples. Can someone take a look? Thanks Vojta [1] https://jenkins.ovirt.org/job/vdsm_standard-check-patch/8277/console [2] https://jenkins.ovirt.org/job/vdsm_standard-check-patch/8285/console [3] https://jenkins.ovirt.org/job/vdsm_standard-check-patch/8291/console

2 1

[Ovirt] [CQ weekly status] [19-07-2019]
by Dusan Fodor 19 Jul '19

19 Jul '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 failure was on 02-07 for ovirt-provider-ovm due to failed test: 098_ovirt_provider_ovn.use_ovn_provide. This was a code regression and which was fixed. *CQ-4.3*: GREEN (#1) Last failure was on 12-07 for ovirt-provider-ovm due to failed build-artifacts which was caused due to a mirror issue. *CQ-Master:* GREEN (#1) Last failure was on 16-07 for ovirt-engine due failure in build-artifacts, which was caused by gerrit issue, which is under investigation by Evgheni. Current running jobs for 4.2 [1], 4.3 [2] and master [3] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.2_change-qu… [2] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.3_change-q… [3] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change… Happy week! Dusan ------------------------------------------------------------------------------------------------------------------- COLOUR MAP Green = job has been passing successfully ** green for more than 3 days may suggest we need a review of our test coverage 1. 1-3 days GREEN (#1) 2. 4-7 days GREEN (#2) 3. Over 7 days GREEN (#3) Yellow = intermittent failures for different projects but no lasting or current regressions ** intermittent would be a healthy project as we expect a number of failures during the week ** I will not report any of the solved failures or regressions. 1. Solved job failures YELLOW (#1) 2. Solved regressions YELLOW (#2) Red = job has been failing ** Active Failures. The colour will change based on the amount of time the project/s has been broken. Only active regressions would be reported. 1. 1-3 days RED (#1) 2. 4-7 days RED (#2) 3. Over 7 days RED (#3) _______________________________________________ Devel mailing list -- devel(a)ovirt.org To unsubscribe send an email to devel-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/YCNCKRK3G4EJX…

1 0

Doubt on Backing Up and Restoring Virtual Machines Using the Backup and Restore API:-
by smidhunraj＠gmail.com 19 Jul '19

19 Jul '19

Doubt on Backing Up and Restoring Virtual Machines Using the Backup and Restore API:- In this link https://ovirt.org/documentation/admin-guide/chap-Backups_and_Migration.html… in point 4 it is said that 4 .Attach the snapshot to the backup virtual machine and activate the disk: POST /api/vms/22222222-2222-2222-2222-222222222222/disks/ HTTP/1.1 Accept: application/xml Content-type: application/xml <disk id="11111111-1111-1111-1111-111111111111"> <snapshot id="11111111-1111-1111-1111-111111111111"/> <active>true</active> </disk> What does this 22222222-2222-2222-2222-222222222222 mean do we need to create a new virtual machine and attach the snapshot to that. Could you kindly explain it further

2 1

OST fails, cannot connect to repo
by Vojtech Juranek 18 Jul '19

18 Jul '19

Hi, OST fails with 09:47:03 https://copr-be.cloud.fedoraproject.org/results/sac/gluster-ansible/ epel-7-x86_64/repodata/repomd.xml: [Errno 14] curl#7 - "Failed connect to copr-be.cloud.fedoraproject.org:443; Connection refused" see e.g. [1] for full log. Stared to fail this morning. Can anyone take a look and fix it? Thanks in advance. Vojta [1] https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5132/console

5 7

HC suite is failing for 3 weeks on vm_run
by Eyal Edri 15 Jul '19

15 Jul '19

FYI, Failing on vm_run test for 4.3: https://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-4.3/lastCom… same on master: https://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-master/last… -- Eyal edri He / Him / His MANAGER CONTINUOUS PRODUCTIZATION SYSTEM ENGINEERING Red Hat <https://www.redhat.com/> <https://red.ht/sig> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ #cp-devel)

2 2

[Ovirt] [CQ weekly status] [12-07-2019]
by Dafna Ron 12 Jul '19

12 Jul '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 failure was on 02-07 for ovirt-provider-ovm due to failed test: 098_ovirt_provider_ovn.use_ovn_provide. This was a code regression and was fixed by patch https://gerrit.ovirt.org/#/c/97072/ *CQ-4.3*: GREEN (#1) Last failure was on 12-07 for ovirt-provider-ovm due to failed build-artifacts which was caused due to a mirror issue. *CQ-Master:* RED (#1) Last failure was on 12-07 for ovirt-provider-ovm due to failed build-artifacts which was caused due to a mirror issue. 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

CI fails to download rpms
by Vojtech Juranek 11 Jul '19

11 Jul '19

Hi, quite a lot of Ci runs fail because Ci fails to download mom-0.5.14-0.0.master.fc29.noarch.rpm, fails with: Downloading Packages: 12:36:34 [MIRROR] mom-0.5.14-0.0.master.fc29.noarch.rpm: Interrupted by header callback: Server reports Content-Length: 133628 but expected size is: 133676 12:36:34 [FAILED] mom-0.5.14-0.0.master.fc29.noarch.rpm: No more mirrors to try - All mirrors were already tried without success 12:36:34 Error: Error downloading packages: 12:36:34 Cannot download noarch/mom-0.5.14-0.0.master.fc29.noarch.rpm: All mirrors were tried for full log, see e.g. [1]. Any idea how to fix it? Thanks Vojta [1] https://jenkins.ovirt.org/job/vdsm_standard-check-patch/7809/console

2 1

[ OST Failure Report ] [ oVirt Master (vdsm) ] [ 10-07-2019 ] [ 004_basic_sanity.vdsm_recovery ]
by Dafna Ron 11 Jul '19

11 Jul '19

Hi, We have a failure on test 004_basic_sanity.vdsm_recovery on basic suite. the error seems to be an error in KSM (invalid arg) can you please have a look? Link and headline of suspected patches: cq identified this as the cause of failure: https://gerrit.ovirt.org/#/c/101603/ - localFsSD: Enable 4k block_size and alignments However, I can see some py3 patches merged at the same time: py3: storage: Fix bytes x string in lvm locking type validation - https://gerrit.ovirt.org/#/c/101124/ Link to Job: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/14963/ Link to all logs: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/14963/artifac… (Relevant) error snippet from the log: <error> s/da0eeccb-5dd8-47e5-9009-8a848fe17ea5.ovirt-guest-agent.0',) {} MainProcess|vm/da0eeccb::DEBUG::2019-07-10 07:53:41,003::supervdsm_server::106::SuperVdsm.ServerCallback::(wrapper) return prepareVmChannel with None MainProcess|jsonrpc/1::DEBUG::2019-07-10 07:54:05,580::supervdsm_server::99::SuperVdsm.ServerCallback::(wrapper) call ksmTune with ({u'pages_to_scan': 64, u'run': 1, u'sleep _millisecs': 89.25152465623417},) {} MainProcess|jsonrpc/1::ERROR::2019-07-10 07:54:05,581::supervdsm_server::103::SuperVdsm.ServerCallback::(wrapper) Error in ksmTune Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/supervdsm_server.py", line 101, in wrapper res = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/supervdsm_api/ksm.py", line 45, in ksmTune f.write(str(v)) IOError: [Errno 22] Invalid argument MainProcess|jsonrpc/5::DEBUG::2019-07-10 07:56:33,211::supervdsm_server::99::SuperVdsm.ServerCallback::(wrapper) call rmAppropriateMultipathRules with ('da0eeccb-5dd8-47e5-9009-8a848fe17ea5',) {} </error>

2 3

Successful 'vdsm-client Host getStats' call on py3
by Marcin Sobczyk 10 Jul '19

10 Jul '19

Hi, I'm currently working on making yajsonrpc/stomp implementation py3-compatible so we can have basic communication with vdsm running on py3. Today for the first time I was able to run vdsm [1] with py3 on fc29 and do a successful 'vdsm-client Host getStats' call. Since these patches are needed for other teams to continue with their work on py3, I'd kindly request those of you who are interested to review them: https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:p… https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:p… https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:p… https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:p… https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:p… https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:p… https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:p… [1] with minor tweak to 'storage.hsm' module

5 11

Access to images in block domain from more VMs
by Tomáš Golembiovský 10 Jul '19

10 Jul '19

Hi, we have a large gap in handling ISO files in data domains and especially on block domains. None of the flows that work with ISOs works (well, one sort of does): 1) Change CD for running VM [1] 2) Attaching boot disk in Run Once -- this works but I wonder if it's by accident, because engine issues spurious teardown on images [2] 3) Guest tools during VM import [3] 4) Automatic attach of guest tools to Windows VMs Before virt can fix all those we need input from storage on how we should handle the images on block domains. The specialty of ISO image is that it makes sense to have it attached to multiple VMs. And that also means something should control whether image needs attaching or whether the image is already attached to the host. Similarly the image should be (attempted to) detached only when there is no longer any VM on the host that uses it. Hence my question to storage -- is there already some framework from storage for handling this? Does it make more sense to do this on engine side or should each host handle it on it's own? To me it seems preferable to handle this on engine side as that is where the requests for attach/detach normally come from (disks in VM import are an exception). It could possibly mean less race conditions (but I may be totally wrong here). Also having it on VDSM side would probably mean changes to the API for 1) and 2). Any input appreciated. Tomas [1] https://bugzilla.redhat.com/show_bug.cgi?id=1589763 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1721455 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1721455 -- Tomáš Golembiovský <tgolembi(a)redhat.com>

3 5