- Devel - oVirt List Archives

Making event types backwards compatible?
by Juan Hernández 29 May '17

29 May '17

Hello, It has been recently requested that the API provides event types: [RFE] Expose event types to API https://bugzilla.redhat.com/1453170 Currently the API provides the event code and description, for example: <event href="/ovirt-engine/api/events/8021" id="8021"> <code>19</code> <description>Host myhost failed to recover.</description ... </event> There is no documentation of what is the meaning of codes, except the source code of the engine itself. This forces some applications to add their own code to name mapping. For example, the 'ovirt' Ruby gem used by older versions of ManageIQ to interact with oVirt contains the following: https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/event.rb#L25-L485 We could avoid this by adding to the API a new event attribute that indicates the type: <event href="/ovirt-engine/api/events/8021" id="8021"> <code>19</code> <type>host_recover_failure</type> <description>Host myhost failed to recover.</description> ... </event> Ideally this should be defined as an enum, so that it will be represented as an enum in the SDKs. Alternatively it could just be an string, and we could reuse the 'name' attribute: <event href="/ovirt-engine/api/events/8021" id="8021"> <code>19</code> <name>host_recover_failure</name> <description>Host myhost failed to recover.</description> ... </event> However, the key point to making this useful would be to keep the types (or names) backwards compatible, so that users of the API can rely on their values and meanings. So this is my question to you: can we commit to keep the names and meanings of the backend event types backwards compatible? Regards, Juan Hernandez

2 2

Fedora wiki: oVirt
by Sandro Bonazzola 29 May '17

29 May '17

Hi, looking at https://fedoraproject.org/wiki/Features/oVirt I think we should state oVirt is not shipped within Fedora anymore and our plans about either abandon the feature or re-target it. Thanks, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

2 1

ovirt-imageio leaves .guestfs-0 folder under /var/tmp during check-patch
by Gil Shinar 28 May '17

28 May '17

Hi, Should it be like that? Is there a way to clean this leftover in the check-patch script? Thanks Gil

6 24

[ENGINE] standardizing query creation
by Allon Mureinik 26 May '17

26 May '17

Hi list, As you may have noticed, there's a bit of an ambiguity on how query objects are created - some have a constructor from a parameters object, some have a constructor from a parameters object and an EngineContext, and some have both. This ambiguity leads to all sorts of annoying bugs where some queries can't be used as internal queries (because they lack the proper constructor), or other queries couldn't be used without a context. I just merged a series of patches to streamline queries creation and eliminate the problem. Looking forwards, queries should have a single constructor receiving a parameters object and a context and pass them on to super. A unit test was added to enforce this constructor's existence in build time. From a caller's perspective, nothing's changed, and all of the Backend#run[Internal]Query methods were left unchanged. The build, CI and OST suite were ran on this patch series and everything seems to be in order, but please let me know if you encounter any issues. -Allon

1 0

upgrade of CL and DC vs running VMs
by Michal Skrivanek 25 May '17

25 May '17

Hi all, I believe that introduction of bug 1413150 (Add warning to change CL to the match the installed engine version) may have an unfortunate consequence of people actually moving forward with the CL and DC without realizing the constraints on running existing VMs. The periodic nagging is likely going to make people run into the following issue even more frequently We have a cluster level override per VM which takes care of compatibility on CL update by setting the VM’s override to the original CL - that is visible in VM properties, but that’s pretty much it, it’s not very prominent at the moment and it can’t be searched on (bug 1454389). When the update cluster change is made there is a dialog informing you, and there’s also the pending config change for those running VMs…until you shut the VM down, from that time on it only has the CL override set. But the real problem is with DC which AFAIK does not have an override capability, and currently does not have any checks for running VMs. With the above mechanism you can easily get a VM with CL override (say. 3.6) and mindlessly updated DC to 4.1…and once you stop such VM you won’t be able to start it anymore as there is a proper check for unsupported 3.6 CL VM in a newer DC (as implemented by bug 1436577 - Solve DC/Cluster upgrade of VMs with now-unsupported custom compatibility level) We either need to warn/block on DC upgrade, or implement some kind of a DC override (I guess this is a storage question?) Thoughts/ideas? Thanks, michal

3 3

OST - possible failure today due to patches in two projects
by Marcin Mirecki 25 May '17

25 May '17

Hi all, Related patches in two different projects were merged today, which might result in the OST's failing for a while until changes from both projects are picked up. The affected test suite: basic-suite-master The affected test scenario: 098_ovirt_provider_ovn The related patches: https://gerrit.ovirt.org/#/c/77028/ https://gerrit.ovirt.org/#/c/77029/ Thanks, Marcin

2 1

ovirt-provider-ovn versioning issue
by Sandro Bonazzola 25 May '17

25 May '17

Hi, noticed you're going to release ovirt-provider-ovn-1.0-8.tar.gz <http://jenkins.ovirt.org/job/ovirt-provider-ovn_4.1_build-artifacts-fc24-x8…> as a new version. Please note that version is usually something like x.y.z and not x.y-r The release suffix is used in general by distribution packagers to address build issues specific to distributions. If tomorrow I'll have to rebuild ovirt-provider-ovn for CentOS or Fedora I'll have to rename the package to: ovirt-provide-ovn-1.0_8-1.fc27 because you're misusing the release suffix in the package naming. Please consider proper versioning for ovirt-provider-ovn. Thanks. -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

2 1

Jenkins was down
by Gil Shinar 24 May '17

24 May '17

Hi all, Our Jenkins had an issue that caused it to use 100% CPU. We needed to restart it and now it is working fine again. If any of you sent patches that had failed to run check-[patch/merged], build-artifa during that time, please retrigger your patches. Sorry and thanks Gil

1 0

test-repo_ovirt_experimental_4.1 failing
by Dusan Fodor 24 May '17

24 May '17

Hello all, experimental 4.1 is failing. Could anyone assist? [first failed job] <http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_exper…> So far i see 3 issues there: - PollVDSCommand error, which has been discussed previously in thread [ovirt-devel] [OST Failure Report][oVirt master][2017-04-11] [log link] <http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_exper…> - wrong gdeploy package 2017-05-23 15:08:42,709::ERROR::root::Wrong distribution for package: gdeploy-2.0.2 [log link] <http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_exper…> - MOM couldn't connect to VDSM [log link] <http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_exper…>

3 4

high performance VM preset
by Michal Skrivanek 24 May '17

24 May '17

Hi all, we plan to work on an improvement in VM definition for high performance workloads which do not require desktop-class devices and generally favor highest possible performance in expense of less flexibility. We’re thinking of adding a new VM preset in addition to current Desktop and Server in New VM dialog, which would automatically pre-select existing options in the right way, and suggest/warn on suboptimal configuration All the presets and warning can be changed and ignored. There are few things we already identified as boosting performance and/or minimize the complexity of the VM, so we plan the preset to: - remove all graphical consoles and set the VM as headless, making it accessible by serial console. - disable all USB. - disable soundcard. - enable I/O Threads, just one for all disks by default. - set host cpu passthrough (effectively disabling VM live migration), add I/O Thread pinning in a similar way as the existing CPU pinning. We plan the following checks and suggest to perform CPU pinning, host topology == guest topology (number of cores per socket and threads per core should match), NUMA topology host and guest match, check and suggest the I/O threads pinning. A popup on a VM dialog save seems suitable. currently identified task and status can be followed on trello card[1] Please share your thoughts, questions, any kind of feedback… Thanks, michal [1] https://trello.com/c/MHRDD8ZO

4 5