- Devel - oVirt List Archives

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

ovirt-engine has been tagged (ovirt-engine-4.3.5.4)
by Tal Nisan 09 Jul '19

09 Jul '19

1 0

vdsm has been tagged (v4.30.24)
by Milan Zamazal 09 Jul '19

09 Jul '19

1 0

OST fail to install hosts: requires: device-mapper = 7:1.02.149-10.el7_6.8 installed: device-mapper-1.02.149-10.el7_6.7.x86_64
by Nir Soffer 08 Jul '19

08 Jul '19

I had 3 failures with OST master: https://jenkins.ovirt.org/blue/organizations/jenkins/ovirt-system-tests_man… https://jenkins.ovirt.org/blue/organizations/jenkins/ovirt-system-tests_man… https://jenkins.ovirt.org/blue/organizations/jenkins/ovirt-system-tests_man… First 2 builds are mostly logging fixes in vdsm and removing dead code, unrelated to the failures. Last build is from master, same patch passed OST today here: https://jenkins.ovirt.org/blue/organizations/jenkins/ovirt-system-tests_man… Looks like some required packages are missing. + yum -y install ovirt-host Error: Package: 7:device-mapper-event-1.02.149-10.el7_6.8.x86_64 (alocalsync) Requires: device-mapper = 7:1.02.149-10.el7_6.8 Installed: 7:device-mapper-1.02.149-10.el7_6.7.x86_64 (installed) device-mapper = 7:1.02.149-10.el7_6.7 Error: Package: systemd-python-219-62.el7_6.7.x86_64 (alocalsync) Requires: systemd-libs = 219-62.el7_6.7 Installed: systemd-libs-219-62.el7_6.6.x86_64 (installed) systemd-libs = 219-62.el7_6.6 Error: Package: systemd-python-219-62.el7_6.7.x86_64 (alocalsync) Requires: systemd = 219-62.el7_6.7 Installed: systemd-219-62.el7_6.6.x86_64 (installed) systemd = 219-62.el7_6.6 Error: Package: libgudev1-219-62.el7_6.7.x86_64 (alocalsync) Requires: systemd-libs = 219-62.el7_6.7 Installed: systemd-libs-219-62.el7_6.6.x86_64 (installed) systemd-libs = 219-62.el7_6.6

3 8

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

05 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*: RED (#1) We are failing because our ost image is centos 7.6 and we now have 7.7 packages. Galit will need to create a new image to fix the failing tests. *CQ-Master:* RED (#1) We are failing because our ost image is centos 7.6 and we now have 7.7 packages. Galit will need to create a new image to fix the failing tests. 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

Proposing Andrej Krejcir as a maintainer of engine core
by Arik Hadas 02 Jul '19

02 Jul '19

Dear engine-core maintainers, I'd like to propose Andrej Krejcir as a maintainer of oVirt engine backend. Since Jul 2015, Andrej has been contributing to ovirt-engine, mostly in SLA areas (scheduling, quota, etc) and recently being more and more involved also in the VIRT areas. This results in ~200 patches to engine master alone. Personally, I reviewed some of Andrej's contributions and noticed reviews made by Andrej to others. I sincerely believe Andrej would be a good addition to the maintainers' group. Thanks in advance for your response!

7 6

ovirt-engine has been tagged (ovirt-engine-4.3.5.3)
by Tal Nisan 02 Jul '19

02 Jul '19

1 0

Storage test case needs to be fixed: 002_bootstrap.resize_and_refresh_storage_domain
by Dafna Ron 02 Jul '19

02 Jul '19

Hi Tal, I am seeing random failures for test 002_bootstrap.resize_and_refresh_storage_domain It looks like this is a timing issue since by the time we print out the error we actually see the resize succeeded. see example below: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/14185/testRep… Can you please assign someone from the storage team to fix this test? Thanks, Dafna

4 14

[ANN] Incubating terraform-provider-ovirt
by Roy Golan 02 Jul '19

02 Jul '19

Hi all, Happy to announce the incubation of a terraform provider[1] for oVirt which is the the result of a community effort started by ESM-MSC institute [2] and then picked up by @imjoey [3] which is now the main maintainer of the project. Terraform with an ovirt provider makes it easy to declaratively create virtualized environments. One usage we will make of it is to create an installer for OKD 4 [4] which will lay an OKD cluster on top of oVirt resources. [1] https://github.com/oVirt/terraform-provider-ovirt [2] https://github.com/EMSL-MSC/terraform-provider-ovirt [3] https://github.com/imjoey/terraform-provider-ovirt [4] https://github.com/openshift/installer Roy

2 1