- Devel - oVirt List Archives

Why filetransaction needs to encode the content to utf-8?
by Yedidyah Bar David 23 Jul '19

23 Jul '19

Hi Nir and all, In [1] you added line 151, to encode the contents to utf-8. Do you remember why you needed that? What happens if I remove this line? I am working on [2]. It fails on that line, because the current content, if organization name is unicode, has a UTF-8 encoded string already, but is a python str (not unicode). Tried patching otopi [3], did a few attempts (some of them also pushed there, check the different patchsets), but none worked. So I am going to patch postinstall file generation instead [4], but I don't like this. Any hints are welcome. Thanks and best regards, [1] https://gerrit.ovirt.org/#/c/92435/1/src/otopi/filetransaction.py [2] https://bugzilla.redhat.com/show_bug.cgi?id=1729511 [3] https://gerrit.ovirt.org/102085 [4] https://gerrit.ovirt.org/102089 -- Didi

3 2

ioprocess-1.2.1 for ovirt 4.3.6
by Nir Soffer 23 Jul '19

23 Jul '19

This is a requirement for supporting 4k in ovirt 4.3.6. We have a build for RHEL: https://bugzilla.redhat.com/1728953 We need build for CentOS 7 - currently providing only: ioprocess-1.1.2-1.el7.x86_64.rpm Vdsm requires 1.2.1 for about 2 weeks, and OST builds pass, probably consuming 1.2.1 from ovirt repositories. https://resources.ovirt.org/repos/ovirt/tested/master/rpm/el7/x86_64/ But CI on 4.3 fails with: Error: Package: vdsm-python-4.30.24-48.gitcc1fe4e.el7.noarch (artifacts) Requires: python-ioprocess >= 1.2.1 Installed: python2-ioprocess-1.1.2-1.201903201036.gita80158c.el7.x86_64 (@tested) python-ioprocess = 1.1.2 Available: python-ioprocess-0.15.1-1.el7.noarch (epel-el7) python-ioprocess = 0.15.1-1.el7 Available: python-ioprocess-0.16.1-1.el7.noarch (centos-ovirt-common-candidate) python-ioprocess = 0.16.1-1.el7 Available: python2-ioprocess-1.1.2-1.el7.x86_64 (centos-ovirt42-testing-x86_64) python-ioprocess = 1.1.2 See https://gerrit.ovirt.org/c/101951/ So either CI on 4.3 is missing the repo providing this version, or this build needs to be elsewhere, probably in: https://cbs.centos.org/repos/virt7-ovirt-43-testing/x86_64/os/Packages/ Nir

4 5

What values should i give in this ovirt api to get the correct response
by smidhunraj＠gmail.com 21 Jul '19

21 Jul '19

I am following this link. https://ovirt.org/documentation/admin-guide/chap-Backups_and_Migration.html… I got response for GET /api/vms/4ef8b995-ae58-49d6-8980-ef0fa6688d92/snapshots/1b94ca4e-8c03-4166-8d29-2b831e24b90e/disks HTTP/1.1 Accept: application/xml Content-type: application/xml Identify disk id "Array ( [disk] => Array ( [0] => Array ( [actual_size] => 0 [alias] => GlanceDisk-8700235 [format] => cow [image_id] => a42bda58-7556-4ebe-a54d-03dc0a3b1f54 [propagate_errors] => false [provisioned_size] => 8589934592 [read_only] => false [shareable] => false [sparse] => true [status] => ok [storage_type] => image [wipe_after_delete] => false [snapshot] => Array ( [id] => 1b94ca4e-8c03-4166-8d29-2b831e24b90e ) [storage_domains] => Array ( [storage_domain] => Array ( [0] => Array ( [id] => ad6aea6d-ff90-457f-98eb-99380949e23a ) ) ) [name] => GlanceDisk-8700235 [description] => CentOS 7 Generic Cloud Image v1711 for x86_64 (8700235) [id] => dded245b-4a73-48b4-a1b4-ba98c37490ad ) What is the values that i have to give to the POST request in this api 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> to replace 1)vms ===>> 22222222-2222-2222-2222-222222222222 2)disk id 11111111-1111-1111-1111-111111111111 3)snapshot id 11111111-1111-1111-1111-111111111111

2 1

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 18 Jul '19

18 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