November 2016 - Devel - oVirt List Archives

Heads-up: moving Libvirt xml creation to the engine
by Arik Hadas 08 Dec '16

08 Dec '16

Hi All, We are working on something that is expected to have a big impact, hence this heads-up. First, we want you to be aware of this change and provide your feedback to make it as good as possible. Second, until the proposed mechanism is fully merged there will be a chase to cover all features unless new features are also implemented with the new mechanism. So please, if you are working on something that adds/changes something in the Libvirt's domain xml, do it with this new mechanism as well (first version would be merged soon). * Goal Creating Libvirt XML in the engine rather than in VDSM. ** Today's flow Engine: VM business entity -> VM properties map VDSM: VM properties map -> Libvirt XML ** Desired flow Engine: VM business entity -> Libvirt XML * Potential Benefits 1. Reduce the number of conversions from 2 to 1, reducing chances for mistakes in the process. 2. Reduce the amount of code in VDSM. 3. Make VM related changes easier - today many of these changes need to be reviewed in 2 projects, this will eliminate the one that tends to take longer. 4. Prevent shortcuts in the form of VDSM-only changes that should be better reflected in the engine. 5. Not to re-generate the XML on each rerun attempt of VM run/migration. 6. Future - not to re-generate the XML on each attempt to auto-start HA VM when using vm-leases (need to make sure we're using the up-to-date VM configuration though). 7. We already found improvements and cleanups that could be made while touching this area (e.g., remove the boot order from devices in the database). * Challenges 1. Not to move host-specific information to the engine. For example, path to storage domain or sockets of channels. The solution is to use place-holders that will be replaced by VDSM. 2. Backward compatibility. 3. The more challenging part is the other direction - that will be the next phase. * Status As a first step, we began with producing the Libvirt XML in the engine by converting the VM properties map to XML in the engine [1] And using the XML that is received as an input in VDSM [2] [1] https://gerrit.ovirt.org/#/c/64473/ [2] https://gerrit.ovirt.org/#/c/65182/ Regards, Arik

11 24

ovirt-appliance (today) is 1.5G...
by Yaniv Kaul 08 Dec '16

08 Dec '16

I'm sure it was less just days ago, but now[1] it is again quite big. 4.0's is 'only' 1G in size[2]. Which anyway raises the question - should we provide delta RPMs for it? Thanks, Y. [1] http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-e… [2] http://resources.ovirt.org/pub/ovirt-4.0-snapshot/rpm/el7/noarch/ovirt-engi…

3 4

Re: [ovirt-devel] ovirt-appliance (today) is 1.5G...
by Ryan Barry 06 Dec '16

06 Dec '16

We may also want to do this with Node/RHV-H eventually (since the updates there are already 500MB). I don't think we currently ship deltarpm on RHV-H, but it's a very small addition. The question is whether makedeltarpm can actually do anything meaningful with something which is already a sparsified image wrapped in an RPM, but I'll test... On Sun, Oct 9, 2016 at 6:35 AM, Doron Fediuck <dfediuck(a)redhat.com> wrote: > FYI > > ---------- Forwarded message ---------- > From: Yaniv Kaul <ykaul(a)redhat.com> > Date: Thu, Oct 6, 2016 at 11:13 AM > Subject: [ovirt-devel] ovirt-appliance (today) is 1.5G... > To: devel <devel(a)ovirt.org> > > > I'm sure it was less just days ago, but now[1] it is again quite big. > 4.0's is 'only' 1G in size[2]. > Which anyway raises the question - should we provide delta RPMs for it? > > Thanks, > Y. > > [1] http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm > /el7/noarch/ovirt-engine-appliance-4.1-20160927.1.el7.centos.noarch.rpm > [2] http://resources.ovirt.org/pub/ovirt-4.0-snapshot/rpm/el > 7/noarch/ovirt-engine-appliance-4.0-20161003.1.el7.centos.noarch.rpm > > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > >

2 2

VDSM changes Linux memory dirty ratios - why?
by Yaniv Kaul 04 Dec '16

04 Dec '16

It appears that VDSM changes the following params: vm.dirty_ratio = 5 vm.dirty_background_ratio = 2 Any idea why? Because we use cache=none it's irrelevant anyway? TIA, Y.

4 9

python path conflicts issues while running python scripts from vdsm verbs
by Ramesh Nachimuthu 02 Dec '16

02 Dec '16

Hi, I am trying to run a python script '/sbin/gluster-eventsapi' in vdsm verb which internally imports some python modules from /usr/lib/python2.7/site-packages/gluster/cliutils/. But it fails with the import error. Following error is seen in the supervdsm log. MainProcess|Thread-1::DEBUG::2016-11-28 16:54:35,130::commands::93::root::(execCmd) FAILED: <err> = 'Traceback (most recent call last):\n File "/sbin/gluster-eventsapi", line 25, in <module>\n from gluster.cliutils.cliutils import (Cmd, execute, node_output_ok, node_output_notok,\nImportError: No module named cliutils.cliutils\n'; <rc> = 1 I think the import statement "from gluster.cliutils.cliutils import (Cmd, execute, node_output_ok, node_output_notok)" in the python script resolves to '/usr/share/vdsm/gluster' instead of /usr/lib/python2.7/site-packages/gluster/cliutils. I see the following in python sys.path while executing a python script from vdsm. ['/usr/libexec/glusterfs', '/usr/share/vdsm', '/usr/lib64/python27.zip', '/usr/lib64/python2.7', '/usr/lib64/python2.7/plat-linux2', '/usr/lib64/python2.7/lib-tk', '/usr/lib64/python2.7/lib-old', '/usr/lib64/python2.7/lib-dynload', '/usr/lib64/python2.7/site-packages', '/usr/lib64/python2.7/site-packages/gtk-2.0', '/usr/lib/python2.7/site-packages'] Looks like '/usr/share/vdsm' take precedence over '/usr/lib64/python2.7/site-packages'. Can someone suggests a way to fix this issue? Note: '/sbin/gluster-eventsapi' works perfectly while running directly from CLI. Related vdsm patch: https://gerrit.ovirt.org/#/c/67168/2/vdsm/gluster/events.py Regards, Ramesh

4 11

Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)
by Barak Korren 01 Dec '16

01 Dec '16

Hi there, I would like to address a concernt that had been raised to us by multiple developers, and reach an agreement on how (and if) to remedy it. Lets assume the following situation: We have a Git repo in Gerrit with top commit C0 in master. On time t0 developers Alice and Bob push patches P1 and P2 respectively to master so that we end up with the following situation in git: C0 <= P1 (this is Alice`s patch) C0 <= P2 (this is Bob`s patch) On time t1 CI runs for both patches checking the code as it looks for each patch. Lets assume CI is successful for both. On time t2 Alice submits her patch and Gerrit merges it, resulting in the following situation in master: C0 <= P1 On time t2 Bob submits his patch. Gerrit, seeing master has changed, re-bases the patch and merges it, the resulting situation (If the rebase is successful) is: C0 <= P1 <= P2 This means that the resulting code was never tested in CI. This, in turn, causes various failures to show up post-merge despite having pre-merge CI run successfully. This situation is a result of the way our repos are currently configured. Most repos ATM are configured with the "Rebase If Necessary" submit type. This means that Gerrit tries to automatically rebase patches as mentioned in t2 above. We could, instead, configure the repos to use the "Fast Forward Only" submit type. In that case, when Bob submits on t2, Gerrit refuses to merge and asks Bob to rebase (While offering a convenient button to do it). When he does, a new patch set gets pushed, and subsequently checked by CI. I recommend we switch all projects to use the "Fast Forward Only" submit type. Thoughts? Concerns? -- Barak Korren bkorren(a)redhat.com RHEV-CI Team

7 17

performance improvements and gwt-rpc switch
by Greg Sheremeta 01 Dec '16

01 Dec '16

Hi everyone, For the upcoming oVirt 4.1, the UX team has been focused hard on webadmin performance improvements. There have been some reports [1] [2] of UI sluggishness in both 3.6 and 4.0, usually after the browser had been open some time, and usually in scale environments. After some research, we determined that the primary cause of this sluggishness was memory leaks. We embarked on several weeks of hunting down memory leak bugs and squashing them. Alexander Wels and Vojtech Szocs led this work, and I helped test the performance of each patch as they created them. As they created patches to squash leaks, performance kept getting better and better. Today we've merged the last of our patches [*], and I'm happy to announce that we are now seeing much better UI performance on 4.1-master and 4.0.6. Over the course of several hours with the browser window open, users should see no sluggishness at all. [*] This last patch switches oVirt from using de-rpc to gwt-rpc in the frontend. This improves performance, but it also allows us to upgrade to GWT 2.8. We'd been previously blocked on that. If you're interested in UI performance testing, continue reading. If not, you can stop here :) ..... To verify our performance improvements, we took some simple measurements using selenium webdriver. The tests were unscientific, but very helpful. We ran a webdriver flow through oVirt that clicked some buttons and tabs and refreshed some grids. We did it a few hundred or thousand times. The tests were run using stubbed hosts (ovirt-vdsmfake) so that only the engine and UI were under test. Below are the important takeaways. The x axis is time, and each point on a graph is a loop through the same webdriver flow. The (ms) y axes are response times, and memory is in MB. In this graph, we compare oVirt 4.1 with and without our most impactful patch applied. As you can see, with the patch applied, response time stays flat for 200 loops of my test script over the course of 18 and 43 minutes. Without the patch applied, response time quickly degraded such that 200 loops of my test script took 1 hr 2 minutes vs. 18 minutes with the patch applied -- a 66% improvement! [image: Inline image 1] In this graph [ignore the spike], we tested oVirt hard for 6 hours 25 minutes (2000 loops). As you can see, the response times stay relatively flat over 6 hours! This is a great improvement. Do note that the memory is still growing, albeit much more slowly now. You can see towards the end of this run, maybe around hour 5, that the deviation starts to go up (the line thickens). Takeaway: maybe refresh your browser after many hours of having webadmin open. But, this is a stress test -- I'm betting users won't notice this slowdown after even 6 hours of regular webadmin use or idling. Last, here is a graph that shows gwt-rpc performing slightly better than de-rpc. Memory consumption is about the same -- gwt-rpc is just a faster rpc implementation. Reply with any questions or concerns. Thanks! Best wishes, Greg [1] https://bugzilla.redhat.com/show_bug.cgi?id=1368101 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1388462 -- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme(a)redhat.com

6 8

aarch64 / Raspberry Pi3
by Sandro Bonazzola 30 Nov '16

30 Nov '16

Hi, some time ago we've been asked to provide aarch64 build of qemu-kvm-ev for CentOS Cloud SIG consumption. We did it, and while at it we also built oVirt 4.0 VDSM dependencies for aarch64 in CentOS Virt SIG. Testing repositories have been created and are now publicly available: [centos-qemu-ev-test] name=CentOS-$releasever - QEMU EV Testing baseurl= http://buildlogs.centos.org/centos/$releasever/virt/$basearch/kvm-common/ gpgcheck=1 enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Virtualization [centos-ovirt40-test] name=CentOS-$releasever - oVirt 4.0 Testing baseurl= http://buildlogs.centos.org/centos/$releasever/virt/$basearch/ovirt-4.0/ gpgcheck=1 enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Virtualization We don't officially support aarch64 and this is highly experimental so expect bugs. But if you've a Raspberry Pi 3 and you decide to give VDSM a run, please share your feedback. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com <https://www.redhat.com/it/about/events/red-hat-open-source-day-2016>

3 2

master won't start
by Greg Sheremeta 30 Nov '16

30 Nov '16

Hi, A fresh checkout of master with a fresh database will not start for me. I tried on two separate machines. ovirt-engine-4.0 branch is still working. Any ideas? Best wishes, Greg 2016-11-29 21:11:33,918-05 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.module.service."deployment.engine.ear.docs.war".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.engine.ear.docs.war".main: WFLYSRV0179: Failed to load module: deployment.engine.ear.docs.war:main at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_101] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_101] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_101] Caused by: org.jboss.modules.ModuleLoadException: Error loading module from /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/module.xml at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:228) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:204) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:170) at org.jboss.modules.LocalModuleFinder.lambda$findModule$3(LocalModuleFinder.java:149) [jboss-modules.jar:1.5.1.Final] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_101] at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:144) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:439) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:342) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:289) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadExportedModule(ModuleLoader.java:300) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:313) [jboss-modules.jar:1.5.1.Final] at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:149) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] at org.jboss.modules.Module.addExportedPaths(Module.java:1229) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.addPaths(Module.java:1121) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.link(Module.java:1448) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.relinkIfNecessary(Module.java:1476) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:225) [jboss-modules.jar:1.5.1.Final] at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] ... 5 more Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to add resource root 'xmlrpc-common.jar' at path 'xmlrpc-common.jar' (position: END_TAG seen ...<resources>\n <resource-root path="xmlrpc-common.jar"/>... @6:46) caused by: java.io.FileNotFoundException: /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/xmlrpc-common.jar (No such file or directory) at org.jboss.modules.xml.ModuleXmlParser.parseResourceRoot(ModuleXmlParser.java:891) at org.jboss.modules.xml.ModuleXmlParser.parseResources(ModuleXmlParser.java:735) at org.jboss.modules.xml.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:535) at org.jboss.modules.xml.ModuleXmlParser.parseDocument(ModuleXmlParser.java:340) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:226) ... 22 more 2016-11-29 21:11:33,915-05 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.module.service."deployment.engine.ear.welcome.war".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.engine.ear.welcome.war".main: WFLYSRV0179: Failed to load module: deployment.engine.ear.welcome.war:main at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_101] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_101] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_101] Caused by: org.jboss.modules.ModuleLoadException: Error loading module from /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/module.xml at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:228) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:204) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:170) at org.jboss.modules.LocalModuleFinder.lambda$findModule$3(LocalModuleFinder.java:149) [jboss-modules.jar:1.5.1.Final] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_101] at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:144) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:439) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:342) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:289) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadExportedModule(ModuleLoader.java:300) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:313) [jboss-modules.jar:1.5.1.Final] at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:149) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] at org.jboss.modules.Module.addExportedPaths(Module.java:1229) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.addPaths(Module.java:1121) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.link(Module.java:1448) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.relinkIfNecessary(Module.java:1476) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:225) [jboss-modules.jar:1.5.1.Final] at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] ... 5 more Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to add resource root 'xmlrpc-common.jar' at path 'xmlrpc-common.jar' (position: END_TAG seen ...<resources>\n <resource-root path="xmlrpc-common.jar"/>... @6:46) caused by: java.io.FileNotFoundException: /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/xmlrpc-common.jar (No such file or directory) at org.jboss.modules.xml.ModuleXmlParser.parseResourceRoot(ModuleXmlParser.java:891) at org.jboss.modules.xml.ModuleXmlParser.parseResources(ModuleXmlParser.java:735) at org.jboss.modules.xml.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:535) at org.jboss.modules.xml.ModuleXmlParser.parseDocument(ModuleXmlParser.java:340) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:226) ... 22 more 2016-11-29 21:11:33,909-05 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.module.service."deployment.engine.ear".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.engine.ear".main: WFLYSRV0179: Failed to load module: deployment.engine.ear:main at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_101] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_101] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_101] Caused by: org.jboss.modules.ModuleLoadException: Error loading module from /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/module.xml at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:228) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:204) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:170) at org.jboss.modules.LocalModuleFinder.lambda$findModule$3(LocalModuleFinder.java:149) [jboss-modules.jar:1.5.1.Final] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_101] at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:144) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:439) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:342) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:289) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadExportedModule(ModuleLoader.java:300) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:313) [jboss-modules.jar:1.5.1.Final] at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:149) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] at org.jboss.modules.Module.addPaths(Module.java:1078) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.link(Module.java:1448) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.relinkIfNecessary(Module.java:1476) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:225) [jboss-modules.jar:1.5.1.Final] at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] ... 5 more Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to add resource root 'xmlrpc-common.jar' at path 'xmlrpc-common.jar' (position: END_TAG seen ...<resources>\n <resource-root path="xmlrpc-common.jar"/>... @6:46) caused by: java.io.FileNotFoundException: /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/xmlrpc-common.jar (No such file or directory) at org.jboss.modules.xml.ModuleXmlParser.parseResourceRoot(ModuleXmlParser.java:891) at org.jboss.modules.xml.ModuleXmlParser.parseResources(ModuleXmlParser.java:735) at org.jboss.modules.xml.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:535) at org.jboss.modules.xml.ModuleXmlParser.parseDocument(ModuleXmlParser.java:340) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:226) ... 21 more 2016-11-29 21:11:33,931-05 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.module.service."deployment.engine.ear.bll.jar".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.engine.ear.bll.jar".main: WFLYSRV0179: Failed to load module: deployment.engine.ear.bll.jar:main at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_101] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_101] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_101] Caused by: org.jboss.modules.ModuleLoadException: Error loading module from /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/module.xml at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:228) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:204) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:170) at org.jboss.modules.LocalModuleFinder.lambda$findModule$3(LocalModuleFinder.java:149) [jboss-modules.jar:1.5.1.Final] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_101] at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:144) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:439) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:342) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:289) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadExportedModule(ModuleLoader.java:300) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:313) [jboss-modules.jar:1.5.1.Final] at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:149) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] at org.jboss.modules.Module.addExportedPaths(Module.java:1229) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.addPaths(Module.java:1121) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.link(Module.java:1448) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.relinkIfNecessary(Module.java:1476) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:225) [jboss-modules.jar:1.5.1.Final] at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] ... 5 more Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to add resource root 'xmlrpc-common.jar' at path 'xmlrpc-common.jar' (position: END_TAG seen ...<resources>\n <resource-root path="xmlrpc-common.jar"/>... @6:46) caused by: java.io.FileNotFoundException: /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/xmlrpc-common.jar (No such file or directory) at org.jboss.modules.xml.ModuleXmlParser.parseResourceRoot(ModuleXmlParser.java:891) at org.jboss.modules.xml.ModuleXmlParser.parseResources(ModuleXmlParser.java:735) at org.jboss.modules.xml.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:535) at org.jboss.modules.xml.ModuleXmlParser.parseDocument(ModuleXmlParser.java:340) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:226) ... 22 more 2016-11-29 21:11:33,953-05 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.module.service."deployment.engine.ear.root.war".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.engine.ear.root.war".main: WFLYSRV0179: Failed to load module: deployment.engine.ear.root.war:main at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_101] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_101] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_101] Caused by: org.jboss.modules.ModuleNotFoundException: org.apache.xmlrpc:main at org.jboss.modules.ModuleLoader$FutureModule.getModule(ModuleLoader.java:651) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:328) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:289) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadExportedModule(ModuleLoader.java:300) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:313) [jboss-modules.jar:1.5.1.Final] at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:149) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] at org.jboss.modules.Module.addExportedPaths(Module.java:1229) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.addPaths(Module.java:1121) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.link(Module.java:1448) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.relinkIfNecessary(Module.java:1476) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:225) [jboss-modules.jar:1.5.1.Final] at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] ... 5 more 2016-11-29 21:11:33,932-05 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.module.service."deployment.engine.ear.services.war".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.engine.ear.services.war".main: WFLYSRV0179: Failed to load module: deployment.engine.ear.services.war:main at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_101] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_101] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_101] Caused by: org.jboss.modules.ModuleLoadException: Error loading module from /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/module.xml at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:228) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:204) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:170) at org.jboss.modules.LocalModuleFinder.lambda$findModule$3(LocalModuleFinder.java:149) [jboss-modules.jar:1.5.1.Final] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_101] at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:144) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:439) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:342) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:289) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadExportedModule(ModuleLoader.java:300) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:313) [jboss-modules.jar:1.5.1.Final] at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:149) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] at org.jboss.modules.Module.addExportedPaths(Module.java:1229) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.addPaths(Module.java:1121) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.link(Module.java:1448) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.relinkIfNecessary(Module.java:1476) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:225) [jboss-modules.jar:1.5.1.Final] at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] ... 5 more Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to add resource root 'xmlrpc-common.jar' at path 'xmlrpc-common.jar' (position: END_TAG seen ...<resources>\n <resource-root path="xmlrpc-common.jar"/>... @6:46) caused by: java.io.FileNotFoundException: /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/xmlrpc-common.jar (No such file or directory) at org.jboss.modules.xml.ModuleXmlParser.parseResourceRoot(ModuleXmlParser.java:891) at org.jboss.modules.xml.ModuleXmlParser.parseResources(ModuleXmlParser.java:735) at org.jboss.modules.xml.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:535) at org.jboss.modules.xml.ModuleXmlParser.parseDocument(ModuleXmlParser.java:340) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:226) ... 22 more 2016-11-29 21:11:33,955-05 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.module.service."deployment.engine.ear.enginesso.war".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.engine.ear.enginesso.war".main: WFLYSRV0179: Failed to load module: deployment.engine.ear.enginesso.war:main at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_101] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_101] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_101] Caused by: org.jboss.modules.ModuleLoadException: Error loading module from /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/module.xml at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:228) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:204) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:170) at org.jboss.modules.LocalModuleFinder.lambda$findModule$3(LocalModuleFinder.java:149) [jboss-modules.jar:1.5.1.Final] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_101] at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:144) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:439) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:342) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:289) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadExportedModule(ModuleLoader.java:300) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:313) [jboss-modules.jar:1.5.1.Final] at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:149) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] at org.jboss.modules.Module.addExportedPaths(Module.java:1229) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.addPaths(Module.java:1121) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.link(Module.java:1448) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.relinkIfNecessary(Module.java:1476) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:225) [jboss-modules.jar:1.5.1.Final] at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] ... 5 more Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to add resource root 'xmlrpc-common.jar' at path 'xmlrpc-common.jar' (position: END_TAG seen ...<resources>\n <resource-root path="xmlrpc-common.jar"/>... @6:46) caused by: java.io.FileNotFoundException: /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/xmlrpc-common.jar (No such file or directory) at org.jboss.modules.xml.ModuleXmlParser.parseResourceRoot(ModuleXmlParser.java:891) at org.jboss.modules.xml.ModuleXmlParser.parseResources(ModuleXmlParser.java:735) at org.jboss.modules.xml.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:535) at org.jboss.modules.xml.ModuleXmlParser.parseDocument(ModuleXmlParser.java:340) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:226) ... 22 more 2016-11-29 21:11:33,965-05 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.module.service."deployment.engine.ear.webadmin.war".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.engine.ear.webadmin.war".main: WFLYSRV0179: Failed to load module: deployment.engine.ear.webadmin.war:main at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_101] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_101] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_101] Caused by: org.jboss.modules.ModuleLoadException: Error loading module from /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/module.xml at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:228) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:204) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:170) at org.jboss.modules.LocalModuleFinder.lambda$findModule$3(LocalModuleFinder.java:149) [jboss-modules.jar:1.5.1.Final] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_101] at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:144) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:439) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:342) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:289) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadExportedModule(ModuleLoader.java:300) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:313) [jboss-modules.jar:1.5.1.Final] at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:149) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] at org.jboss.modules.Module.addExportedPaths(Module.java:1229) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.addPaths(Module.java:1121) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.link(Module.java:1448) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.relinkIfNecessary(Module.java:1476) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:225) [jboss-modules.jar:1.5.1.Final] at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] ... 5 more Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to add resource root 'xmlrpc-common.jar' at path 'xmlrpc-common.jar' (position: END_TAG seen ...<resources>\n <resource-root path="xmlrpc-common.jar"/>... @6:46) caused by: java.io.FileNotFoundException: /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/xmlrpc-common.jar (No such file or directory) at org.jboss.modules.xml.ModuleXmlParser.parseResourceRoot(ModuleXmlParser.java:891) at org.jboss.modules.xml.ModuleXmlParser.parseResources(ModuleXmlParser.java:735) at org.jboss.modules.xml.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:535) at org.jboss.modules.xml.ModuleXmlParser.parseDocument(ModuleXmlParser.java:340) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:226) ... 22 more 2016-11-29 21:11:33,986-05 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.module.service."deployment.engine.ear.userportal.war".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.engine.ear.userportal.war".main: WFLYSRV0179: Failed to load module: deployment.engine.ear.userportal.war:main at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_101] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_101] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_101] Caused by: org.jboss.modules.ModuleLoadException: Error loading module from /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/module.xml at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:228) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:204) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:170) at org.jboss.modules.LocalModuleFinder.lambda$findModule$3(LocalModuleFinder.java:149) [jboss-modules.jar:1.5.1.Final] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_101] at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:144) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:439) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:342) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:289) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadExportedModule(ModuleLoader.java:300) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:313) [jboss-modules.jar:1.5.1.Final] at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:149) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] at org.jboss.modules.Module.addExportedPaths(Module.java:1229) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.addPaths(Module.java:1121) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.link(Module.java:1448) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.Module.relinkIfNecessary(Module.java:1476) [jboss-modules.jar:1.5.1.Final] at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:225) [jboss-modules.jar:1.5.1.Final] at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68) [wildfly-server-2.0.10.Final.jar:2.0.10.Final] ... 5 more Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to add resource root 'xmlrpc-common.jar' at path 'xmlrpc-common.jar' (position: END_TAG seen ...<resources>\n <resource-root path="xmlrpc-common.jar"/>... @6:46) caused by: java.io.FileNotFoundException: /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/xmlrpc-common.jar (No such file or directory) at org.jboss.modules.xml.ModuleXmlParser.parseResourceRoot(ModuleXmlParser.java:891) at org.jboss.modules.xml.ModuleXmlParser.parseResources(ModuleXmlParser.java:735) at org.jboss.modules.xml.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:535) at org.jboss.modules.xml.ModuleXmlParser.parseDocument(ModuleXmlParser.java:340) at org.jboss.modules.xml.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:226) ... 22 more 2016-11-29 21:11:33,990-05 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "restapi.war")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => [ "jboss.naming.context.java.module.restapi.restapi.env.\"org.ovirt.engine.api.restapi.security.CORSSupportFilter\".backend is missing [jboss.naming.context.java.global.engine.bll.\"Backend!org.ovirt.engine.core.common.interfaces.BackendLocal\"]", "jboss.naming.context.java.module.restapi.restapi.env.\"org.ovirt.engine.api.restapi.invocation.CurrentFilter\".backend is missing [jboss.naming.context.java.global.engine.bll.\"Backend!org.ovirt.engine.core.common.interfaces.BackendLocal\"]" ]} 2016-11-29 21:11:33,993-05 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "engine.ear")]) - failure description: { "WFLYCTL0080: Failed services" => { "jboss.module.service.\"deployment.engine.ear.welcome.war\".main" => "org.jboss.msc.service.StartException in service jboss.module.service.\"deployment.engine.ear.welcome.war\".main: WFLYSRV0179: Failed to load module: deployment.engine.ear.welcome.war:main Caused by: org.jboss.modules.ModuleLoadException: Error loading module from /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/module.xml Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to add resource root 'xmlrpc-common.jar' at path 'xmlrpc-common.jar' (position: END_TAG seen ...<resources>\\n <resource-root path=\"xmlrpc-common.jar\"/>... @6:46) caused by: java.io.FileNotFoundException: /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/xmlrpc-common.jar (No such file or directory)", "jboss.module.service.\"deployment.engine.ear.webadmin.war\".main" => "org.jboss.msc.service.StartException in service jboss.module.service.\"deployment.engine.ear.webadmin.war\".main: WFLYSRV0179: Failed to load module: deployment.engine.ear.webadmin.war:main Caused by: org.jboss.modules.ModuleLoadException: Error loading module from /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/module.xml Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to add resource root 'xmlrpc-common.jar' at path 'xmlrpc-common.jar' (position: END_TAG seen ...<resources>\\n <resource-root path=\"xmlrpc-common.jar\"/>... @6:46) caused by: java.io.FileNotFoundException: /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/xmlrpc-common.jar (No such file or directory)", "jboss.module.service.\"deployment.engine.ear.enginesso.war\".main" => "org.jboss.msc.service.StartException in service jboss.module.service.\"deployment.engine.ear.enginesso.war\".main: WFLYSRV0179: Failed to load module: deployment.engine.ear.enginesso.war:main Caused by: org.jboss.modules.ModuleLoadException: Error loading module from /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/module.xml Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to add resource root 'xmlrpc-common.jar' at path 'xmlrpc-common.jar' (position: END_TAG seen ...<resources>\\n <resource-root path=\"xmlrpc-common.jar\"/>... @6:46) caused by: java.io.FileNotFoundException: /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/xmlrpc-common.jar (No such file or directory)", "jboss.module.service.\"deployment.engine.ear\".main" => "org.jboss.msc.service.StartException in service jboss.module.service.\"deployment.engine.ear\".main: WFLYSRV0179: Failed to load module: deployment.engine.ear:main Caused by: org.jboss.modules.ModuleLoadException: Error loading module from /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/module.xml Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to add resource root 'xmlrpc-common.jar' at path 'xmlrpc-common.jar' (position: END_TAG seen ...<resources>\\n <resource-root path=\"xmlrpc-common.jar\"/>... @6:46) caused by: java.io.FileNotFoundException: /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/xmlrpc-common.jar (No such file or directory)", "jboss.module.service.\"deployment.engine.ear.userportal.war\".main" => "org.jboss.msc.service.StartException in service jboss.module.service.\"deployment.engine.ear.userportal.war\".main: WFLYSRV0179: Failed to load module: deployment.engine.ear.userportal.war:main Caused by: org.jboss.modules.ModuleLoadException: Error loading module from /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/module.xml Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to add resource root 'xmlrpc-common.jar' at path 'xmlrpc-common.jar' (position: END_TAG seen ...<resources>\\n <resource-root path=\"xmlrpc-common.jar\"/>... @6:46) caused by: java.io.FileNotFoundException: /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/xmlrpc-common.jar (No such file or directory)", "jboss.module.service.\"deployment.engine.ear.root.war\".main" => "org.jboss.msc.service.StartException in service jboss.module.service.\"deployment.engine.ear.root.war\".main: WFLYSRV0179: Failed to load module: deployment.engine.ear.root.war:main Caused by: org.jboss.modules.ModuleNotFoundException: org.apache.xmlrpc:main", "jboss.module.service.\"deployment.engine.ear.docs.war\".main" => "org.jboss.msc.service.StartException in service jboss.module.service.\"deployment.engine.ear.docs.war\".main: WFLYSRV0179: Failed to load module: deployment.engine.ear.docs.war:main Caused by: org.jboss.modules.ModuleLoadException: Error loading module from /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/module.xml Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to add resource root 'xmlrpc-common.jar' at path 'xmlrpc-common.jar' (position: END_TAG seen ...<resources>\\n <resource-root path=\"xmlrpc-common.jar\"/>... @6:46) caused by: java.io.FileNotFoundException: /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/xmlrpc-common.jar (No such file or directory)", "jboss.module.service.\"deployment.engine.ear.bll.jar\".main" => "org.jboss.msc.service.StartException in service jboss.module.service.\"deployment.engine.ear.bll.jar\".main: WFLYSRV0179: Failed to load module: deployment.engine.ear.bll.jar:main Caused by: org.jboss.modules.ModuleLoadException: Error loading module from /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/module.xml Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to add resource root 'xmlrpc-common.jar' at path 'xmlrpc-common.jar' (position: END_TAG seen ...<resources>\\n <resource-root path=\"xmlrpc-common.jar\"/>... @6:46) caused by: java.io.FileNotFoundException: /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/xmlrpc-common.jar (No such file or directory)", "jboss.module.service.\"deployment.engine.ear.services.war\".main" => "org.jboss.msc.service.StartException in service jboss.module.service.\"deployment.engine.ear.services.war\".main: WFLYSRV0179: Failed to load module: deployment.engine.ear.services.war:main Caused by: org.jboss.modules.ModuleLoadException: Error loading module from /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/module.xml Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to add resource root 'xmlrpc-common.jar' at path 'xmlrpc-common.jar' (position: END_TAG seen ...<resources>\\n <resource-root path=\"xmlrpc-common.jar\"/>... @6:46) caused by: java.io.FileNotFoundException: /home/greg/ovirt-engine/share/ovirt-engine/modules/common/org/apache/xmlrpc/main/xmlrpc-common.jar (No such file or directory)" }, "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => { "Services that were unable to start:" => [ "jboss.deployment.subunit.\"engine.ear\".\"bll.jar\".FIRST_MODULE_USE", "jboss.deployment.subunit.\"engine.ear\".\"docs.war\".FIRST_MODULE_USE", "jboss.deployment.subunit.\"engine.ear\".\"enginesso.war\".FIRST_MODULE_USE", "jboss.deployment.subunit.\"engine.ear\".\"root.war\".FIRST_MODULE_USE", "jboss.deployment.subunit.\"engine.ear\".\"services.war\".FIRST_MODULE_USE", "jboss.deployment.subunit.\"engine.ear\".\"userportal.war\".FIRST_MODULE_USE", "jboss.deployment.subunit.\"engine.ear\".\"webadmin.war\".FIRST_MODULE_USE", "jboss.deployment.subunit.\"engine.ear\".\"welcome.war\".FIRST_MODULE_USE", "jboss.deployment.unit.\"engine.ear\".FIRST_MODULE_USE" ], "Services that may be the cause:" => ["jboss.naming.context.java.global.engine.bll.\"Backend!org.ovirt.engine.core.common.interfaces.BackendLocal\""] } } 2016-11-29 21:11:34,012-05 INFO [org.jboss.as.server] (ServerService Thread Pool -- 25) WFLYSRV0010: Deployed "engine.ear" (runtime-name : "engine.ear") 2016-11-29 21:11:34,012-05 INFO [org.jboss.as.server] (ServerService Thread Pool -- 25) WFLYSRV0010: Deployed "apidoc.war" (runtime-name : "apidoc.war") 2016-11-29 21:11:34,012-05 INFO [org.jboss.as.server] (ServerService Thread Pool -- 25) WFLYSRV0010: Deployed "restapi.war" (runtime-name : "restapi.war") 2016-11-29 21:11:34,014-05 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report WFLYCTL0184: New missing/unsatisfied dependencies: -- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme(a)redhat.com

3 6

[RFC] Communicating within the community [was Re: [ovirt-users] I wrote an oVirt thing]
by Sandro Bonazzola 29 Nov '16

29 Nov '16

Moving to devel since this needs developer attention On Tue, Nov 29, 2016 at 2:50 PM, Logan Kuhn <logank(a)wolfram.com> wrote: > Is this something that was officially announced and I've missed? This is > the first time I'm hearing about the removal of the cli > > I tend to agree with Logan here, we have a lack of communication on what's going on. We haven't weekly status meetings anymore, the experiment on office hours didn't work and progress reports to mailing lists are not sent anymore. We need to rethink the way we propagate information. Up to now the only way we have to give info on coming deprecation is the release notes page which is built from bugzilla doctext so if no other way is used to communicate changes, at least please use a bug. > Regards, > Logan > > -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

4 3

planned jenkins and resources downtime
by Evgheni Dereveanchin 29 Nov '16

29 Nov '16

Hi everyone, As part of a planned maintenance window I am going to apply OS updates and reboot the Jenkins master along with our resources file server. Affected services: jenkins.ovirt.org resources.ovirt.org This means that no new jobs will be started on the Jenkins and our repositories will be unavailable for a short period of time. I will follow up on this email once all services are back up and running. Regards, Evgheni Dereveanchin

1 1

Re: [ovirt-devel] [JIRA] (OVIRT-416) [standard-ci] build-artifacts should reuse the artifacts built on check-merged if any
by Vojtech Szocs 29 Nov '16

29 Nov '16

Hi, > Any patches sent on this? I'd like to help. Looking at the recent Engine (master) build: http://jenkins.ovirt.org/job/ovirt-engine_master_build-artifacts-el7-x86_64… $ rpm -qlp ovirt-engine-webadmin-portal-4.1.0-0.0.master.20161125171318.gitae69c34.el7.centos.noarch.rpm it shows we still build all [browser x language] GWT permutations, basically there are tons of <md5>.cache.js files in `webadmin.war` directory (each one represents a single permutation). In automation/build-artifacts.sh, we could add some variable that controls what kind of GWT build to do (e.g. GWT_BUILD_MODE): 1, snapshot GWT build: all supported browsers x en_US (only) => 3 x 1 = 3 GWT permutations 2, full GWT build: all supported browsers x all supported locales => 3 x 9 = 27 (!) GWT permutations With "snapshot GWT build", we should do: rpmbuild \ .. existing stuff -D "ovirt_build_locales 0" \ .. existing stuff GWT_BUILD_MODE can default to "full GWT build". But how do we override GWT_BUILD_MODE when doing non-release builds? Regards, Vojtech ----- Original Message ----- > From: "eyal edri [Administrator] (oVirt JIRA)" <jira(a)ovirt-jira.atlassian.net> > To: infra(a)ovirt.org > Sent: Sunday, November 6, 2016 4:29:02 PM > Subject: [JIRA] (OVIRT-416) [standard-ci] build-artifacts should reuse the artifacts built on check-merged if any > > > [ > https://ovirt-jira.atlassian.net/browse/OVIRT-416?page=com.atlassian.jira.p… > ] > > eyal edri [Administrator] commented on OVIRT-416: > ------------------------------------------------- > > Any patches sent on this? > Also, wanted to mention #OVIRT-751 is handling similar purpose with enabling > better maven caching, so it might suffice as a starting point in optimizing > ovirt-engine runtime for builds. > > > [standard-ci] build-artifacts should reuse the artifacts built on > > check-merged if any > > ------------------------------------------------------------------------------------- > > > > Key: OVIRT-416 > > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-416 > > Project: oVirt - virtualization made easy > > Issue Type: Improvement > > Reporter: David Caro Estevez > > Assignee: infra > > > > Right now most projects just rebuild twice the artifacts, what for some > > means a big waste of resources, if we could just reuse what was built > > previously there would be no rebuilding. > > Something to take into account is that the distributions that check-merged > > and build-artifacts run for might not match, so you can be running > > check-merged only on fc23 but building artifacts for fc23, fc22 an el7 (as > > an example), maybe we should not allow different distros on each stage?| > > > > -- > This message was sent by Atlassian JIRA > (v1000.499.4#100018) > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra >

2 2

oVirt 4.1.0 beta1 compose planned
by Sandro Bonazzola 29 Nov '16

29 Nov '16

Fyi oVirt developers, An oVirt compose is planned for this Thursday 11:00 AM TLV time (10:00 AM CET). Please note this will be the first oVirt 4.1 beta compose and will be done taking master snapshot in its state at compose time. If you've pending fixes to be published please ping me at least 40 minutes before the scheduled time. A list of pending blockers is available here: https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.1.… -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Allow editing hosted engine configuration on shared storage
by Evgenia Tokar 29 Nov '16

29 Nov '16

Hi, I'm working on a feature that will allow editing hosted engine configuration on shared storage (currently it can't be easily accessed or modified). This is the link to the pull request for the feature page: https://github.com/oVirt/ovirt-site/pull/621 Any comments are welcome. Thanks, Jenny Tokar SLA / oVirt

1 0

Create soft-host-to-vm-affinity-support feature
by Yanir Quinn 29 Nov '16

29 Nov '16

Hi, I have posted a pull request for soft-host-to-vm-affinity-support feature : https://github.com/oVirt/ovirt-site/pull/611 The feature comes to support the following use case: *Certain set of VMs form a logical management unit should run on a certain set of hosts for SLA or management (e.g. a separate rack for each customer). The VMs can run anywhere in case the dedicated rack needs to be turned off, but should return to their dedicated hosts once the rack is back up.* comments/remarks/other suggestions will be appreciated. -- Yanir Quinn SLA / ovirt

1 0

[Call for Vote] moVirt as a Full oVirt Project
by Brian Proffitt 29 Nov '16

29 Nov '16

All: The moVirt Project was initially accepted as an oVirt incubator project in February 2015. It has been a successful subproject for quite some time and it is well due for being accepted as a full oVirt project. I believe it is appropriate to post a Call for Vote on the Devel and Board lists. http://www.ovirt.org/develop/projects/project-movirt/ A “healthy” project, as determined by the oVirt Board, can be found at http://www.ovirt.org/develop/projects/adding-a-new-project/ Voting will be open until 1200 UTC Nov. 30, 2016. A net total of +7 votes should be received to formalize this project as an full oVirt project. Please use the following vote process: +1 Yes, agree, or the action should be performed. On some issues, this vote must only be given after the voter has tested the action on their own system(s). ±0 Abstain, no opinion, or I am happy to let the other group members decide this issue. An abstention may have detrimental affects if too many people abstain. -1 No, I veto this action. All vetos must include an explanation of why the veto is appropriate. A veto with no explanation is void. Thank you! Brian Proffitt Principal Community Analyst Open Source and Standards @TheTechScribe 574.383.9BKP

19 24

ovirt-engine-api-explorer - webpack, command not found
by Sandro Bonazzola 29 Nov '16

29 Nov '16

The following job is failing on missing webpack: http://jenkins.ovirt.org/job/ovirt-engine-api-explorer_master_build-artifac… can you please fix? -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1

oVirt 4.0.6 RC3 merge / branch / tag / bugzilla reminder
by Sandro Bonazzola 28 Nov '16

28 Nov '16

All stable branch maintainers, please make sure to merge all relevant open bugs until Wednesday morning 11:00 AM TLV time (10:00 AM CET). For each package that need to be built (i.e oVirt product) please make sure every bug in MODIFIED has the right Target Release and Target Milestone. A Target release should state the version of the package you're building and should include the same version you used for the tag you just used for this build. (e.g. for ovirt-engine, tag: ovirt-engine-4.0.6, tr: 4.0.6) A list of bugs that require attention is here: https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.… -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

oVirt 4.0.6 RC3 build planned
by Sandro Bonazzola 28 Nov '16

28 Nov '16

Fyi oVirt developers, An oVirt build is planned for this Wednesday 11:00 AM TLV time (10:00 AM CET). Taking into consideration the time it takes for Jenkins to run a full CI everything need to be backported by Tuesday 11PM. Please make sure to mark as verified and CR +2 so it will be ready for merging Wednesday morning. A list of pending blockers is available here: https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.… -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

[VDSM] Flaky network tests
by Nir Soffer 28 Nov '16

28 Nov '16

Hi all, I'm seeing new random network test failures - see bellow. The interesting thing is I don't see these errors at all in travis. Maybe mark this as brokne_on_ci? 21:35:54 ====================================================================== 21:35:54 ERROR: test_event_groups (network.netlink_test.NetlinkEventMonitorTests) 21:35:54 ---------------------------------------------------------------------- 21:35:54 Traceback (most recent call last): 21:35:54 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/testValidation.py", line 97, in wrapper 21:35:54 return f(*args, **kwargs) 21:35:54 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/network/netlink_test.py", line 94, in test_event_groups 21:35:54 for event in mon_a: 21:35:54 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/vdsm/network/netlink/monitor.py", line 115, in __iter__ 21:35:54 raise MonitorError(E_TIMEOUT) 21:35:54 MonitorError: 2 21:35:54 -------------------- >> begin captured logging << -------------------- 21:35:54 2016-11-27 21:35:18,631 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-3 /sbin/ip link add name dummy_0JsyI type dummy (cwd None) (commands:69) 21:35:54 2016-11-27 21:35:18,944 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:35:54 2016-11-27 21:35:18,962 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-3 /sbin/ip -4 addr add dev dummy_0JsyI 192.0.2.1/24 (cwd None) (commands:69) 21:35:54 2016-11-27 21:35:19,342 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:35:54 2016-11-27 21:35:19,353 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-3 /sbin/ip link set dev dummy_0JsyI up (cwd None) (commands:69) 21:35:54 2016-11-27 21:35:19,649 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:35:54 2016-11-27 21:35:19,661 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-3 /sbin/ip link del dev dummy_0JsyI (cwd None) (commands:69) 21:35:54 2016-11-27 21:35:19,948 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:35:54 --------------------- >> end captured logging << ---------------------

3 5

Scheduling policy weight normalization 4.1 feature
by Martin Sivak 28 Nov '16

28 Nov '16

Hi, I just posted a pull request for the mentioned feature. https://github.com/oVirt/ovirt-site/pull/614 The feature is about an internal change to the VM scheduling algorithm that should make the behaviour of the policy unit multiplier buttons more predictable. Any additional comments or insights are welcome. -- Martin Sivák SLA / oVirt

1 0

[VDSM] Old network flaky test
by Nir Soffer 27 Nov '16

27 Nov '16

HI all, This test is failing randomly for few long time. I think it is time to mark it as broken_on_ci. 23:44:53 ====================================================================== 23:44:53 FAIL: test_ip_info (network.netinfo_test.TestNetinfo) 23:44:53 ---------------------------------------------------------------------- 23:44:53 Traceback (most recent call last): 23:44:53 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/testValidation.py", line 97, in wrapper 23:44:53 return f(*args, **kwargs) 23:44:53 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/network/netinfo_test.py", line 384, in test_ip_info 23:44:53 [IPV6_ADDR_CIDR])) 23:44:53 AssertionError: Tuples differ: ('192.0.2.2', '255.255.255.0',... != ('192.0.2.2', '255.255.255.0',... 23:44:53 23:44:53 First differing element 2: 23:44:53 ['192.0.2.2/24', '198.51.100.9/24', '198.51.100.11/32'] 23:44:53 ['192.0.2.2/24', '198.51.100.9/24', '198.51.100.11/32', '192.0.2.3/24'] 23:44:53 23:44:53 ('192.0.2.2', 23:44:53 '255.255.255.0', 23:44:53 - ['192.0.2.2/24', '198.51.100.9/24', '198.51.100.11/32'], 23:44:53 + ['192.0.2.2/24', '198.51.100.9/24', '198.51.100.11/32', '192.0.2.3/24'], 23:44:53 ? ++++++++++++++++ 23:44:53 23:44:53 ['2607:f0d0:1002:51::4/64']) 23:44:53 -------------------- >> begin captured logging << -------------------- 23:44:53 2016-11-27 23:44:29,240 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-1 /sbin/ip link add name dummy_zjpxS type dummy (cwd None) (commands:69) 23:44:53 2016-11-27 23:44:29,263 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 23:44:53 2016-11-27 23:44:29,265 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-1 /sbin/ip link set dev dummy_zjpxS up (cwd None) (commands:69) 23:44:53 2016-11-27 23:44:29,294 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 23:44:53 2016-11-27 23:44:29,299 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-1 /sbin/ip -4 addr add dev dummy_zjpxS 192.0.2.2/24 (cwd None) (commands:69) 23:44:53 2016-11-27 23:44:29,311 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 23:44:53 2016-11-27 23:44:29,315 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-1 /sbin/ip -4 addr add dev dummy_zjpxS 192.0.2.3/24 (cwd None) (commands:69) 23:44:53 2016-11-27 23:44:29,329 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 23:44:53 2016-11-27 23:44:29,331 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-1 /sbin/ip -4 addr add dev dummy_zjpxS 198.51.100.9/24 (cwd None) (commands:69) 23:44:53 2016-11-27 23:44:29,341 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 23:44:53 2016-11-27 23:44:29,345 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-1 /sbin/ip -6 addr add dev dummy_zjpxS 2607:f0d0:1002:51::4/64 (cwd None) (commands:69) 23:44:53 2016-11-27 23:44:29,356 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 23:44:53 2016-11-27 23:44:29,358 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-1 /sbin/ip -4 addr add dev dummy_zjpxS 198.51.100.11/32 (cwd None) (commands:69) 23:44:53 2016-11-27 23:44:29,370 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 23:44:53 2016-11-27 23:44:29,379 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-1 /sbin/ip link del dev dummy_zjpxS (cwd None) (commands:69) 23:44:53 2016-11-27 23:44:29,401 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 23:44:53 --------------------- >> end captured logging << ---------------------

1 2

[VDSM] Flaky stoarge test
by Nir Soffer 27 Nov '16

27 Nov '16

Hi all, This the second time I see this error - please report if you saw this error in your tests. The suspicious thing is this line: 21:32:59 2016-11-27 21:30:34,890 DEBUG (MainThread) [root] SUCCESS: <err> = "can't open device /var/tmp/tmpA0v1m6/vol0.img: Image is not in qcow2 format\nno file open, try 'help open'\n"; <rc> = 0 (commands:93) qemu-io command succeeded - but it logs very alerting error... I think Kevin Wolf would like to see this. Ala, can you investigate this? 21:32:59 ====================================================================== 21:32:59 FAIL: test_commit('1.1', 0, 1, True) (qemuimg_test.TestCommit) 21:32:59 ---------------------------------------------------------------------- 21:32:59 Traceback (most recent call last): 21:32:59 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/testlib.py", line 135, in wrapper 21:32:59 return f(self, *args) 21:32:59 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/qemuimg_test.py", line 425, in test_commit 21:32:59 self.assertEqual(os.stat(vol).st_blocks, blocks) 21:32:59 AssertionError: 648 != 776 21:32:59 -------------------- >> begin captured logging << -------------------- 21:32:59 2016-11-27 21:30:33,960 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-15 /usr/bin/qemu-img create -f raw /var/tmp/tmpA0v1m6/vol0.img 1048576 (cwd None) (commands:69) 21:32:59 2016-11-27 21:30:33,989 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:32:59 2016-11-27 21:30:33,990 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-15 qemu-io -f raw -c 'write -P 240 0 1024' /var/tmp/tmpA0v1m6/vol0.img (cwd None) (commands:69) 21:32:59 2016-11-27 21:30:34,049 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:32:59 2016-11-27 21:30:34,050 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-15 /usr/bin/qemu-img create -f qcow2 -o compat=1.1 -b /var/tmp/tmpA0v1m6/vol0.img /var/tmp/tmpA0v1m6/vol1.img 1048576 (cwd None) (commands:69) 21:32:59 2016-11-27 21:30:34,117 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:32:59 2016-11-27 21:30:34,118 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-15 qemu-io -f qcow2 -c 'write -P 241 1024 1024' /var/tmp/tmpA0v1m6/vol1.img (cwd None) (commands:69) 21:32:59 2016-11-27 21:30:34,282 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:32:59 2016-11-27 21:30:34,282 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-15 /usr/bin/qemu-img create -f qcow2 -o compat=1.1 -b /var/tmp/tmpA0v1m6/vol1.img /var/tmp/tmpA0v1m6/vol2.img 1048576 (cwd None) (commands:69) 21:32:59 2016-11-27 21:30:34,334 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:32:59 2016-11-27 21:30:34,334 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-15 qemu-io -f qcow2 -c 'write -P 242 2048 1024' /var/tmp/tmpA0v1m6/vol2.img (cwd None) (commands:69) 21:32:59 2016-11-27 21:30:34,515 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:32:59 2016-11-27 21:30:34,515 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-15 /usr/bin/qemu-img create -f qcow2 -o compat=1.1 -b /var/tmp/tmpA0v1m6/vol2.img /var/tmp/tmpA0v1m6/vol3.img 1048576 (cwd None) (commands:69) 21:32:59 2016-11-27 21:30:34,577 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:32:59 2016-11-27 21:30:34,577 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-15 qemu-io -f qcow2 -c 'write -P 243 3072 1024' /var/tmp/tmpA0v1m6/vol3.img (cwd None) (commands:69) 21:32:59 2016-11-27 21:30:34,750 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:32:59 2016-11-27 21:30:34,751 DEBUG (MainThread) [QemuImg] /usr/bin/taskset --cpu-list 0-15 /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /usr/bin/qemu-img commit -p -t none -b /var/tmp/tmpA0v1m6/vol0.img -f qcow2 /var/tmp/tmpA0v1m6/vol1.img (cwd /var/tmp/tmpA0v1m6) (qemuimg:257) 21:32:59 2016-11-27 21:30:34,817 DEBUG (MainThread) [QemuImg] qemu-img operation progress: 100.0% (qemuimg:323) 21:32:59 2016-11-27 21:30:34,818 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-15 qemu-io -f raw -c 'read -P 240 -s 0 -l 1024 0 1024' /var/tmp/tmpA0v1m6/vol0.img (cwd None) (commands:69) 21:32:59 2016-11-27 21:30:34,856 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:32:59 2016-11-27 21:30:34,857 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-15 qemu-io -f qcow2 -c 'read -P 241 -s 0 -l 1024 1024 1024' /var/tmp/tmpA0v1m6/vol0.img (cwd None) (commands:69) 21:32:59 2016-11-27 21:30:34,890 DEBUG (MainThread) [root] SUCCESS: <err> = "can't open device /var/tmp/tmpA0v1m6/vol0.img: Image is not in qcow2 format\nno file open, try 'help open'\n"; <rc> = 0 (commands:93) 21:32:59 --------------------- >> end captured logging << ---------------------

1 0

Gerrit headers are not added to commits in vdsm repo
by Tomáš Golembiovský 27 Nov '16

27 Nov '16

Hi, I've noticed that in vdsm repo the merged commits do not contain the info headers added by Gerrit any more (Reviewed-by/Reviewed-on/etc.). Is that intentional? If yes, what was the motivation behind this? The change seem to have happened about 4 days ago. Sometime between the following two commits: * 505f5da API: Introduce getQemuImageInfo API. [Maor Lipchuk] * 1c4a39c protocoldetector: Avoid unneeded getpeername() [Nir Soffer] Thanks, Tomas -- Tomáš Golembiovský <tgolembi(a)redhat.com>

5 7

[VDSM] test_import_modules randomly failing on travis
by Nir Soffer 26 Nov '16

26 Nov '16

Hi all, Vdsm travis tests are running file for some weeks. We have several random failures, probably bad tests that needs to be fixed. The most common failure is this - failing only in python 3. ====================================================================== ERROR: test_import_modules(('a.py', 'b.py', 'a.pyc', 'a.pyioas'), ('a', 'b')) (moduleloader_test.ImportModulesTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/vdsm/tests/testlib.py", line 135, in wrapper return f(self, *args) File "/vdsm/tests/moduleloader_test.py", line 51, in test_import_modules with self._setup_test_modules(files) as module_name: File "/usr/lib64/python3.5/contextlib.py", line 59, in __enter__ return next(self.gen) File "/vdsm/tests/moduleloader_test.py", line 42, in _setup_test_modules yield importlib.import_module(os.path.basename(path)) File "/usr/lib64/python3.5/importlib/__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 986, in _gcd_import File "<frozen importlib._bootstrap>", line 969, in _find_and_load File "<frozen importlib._bootstrap>", line 956, in _find_and_load_unlocked ImportError: No module named 'tmpozng7rht' See complete run: https://travis-ci.org/nirs/vdsm/jobs/178894634 Piotr, can you check why this fail and get this test working on travis? Thanks, Nir

2 3

Re: [ovirt-devel] [ovirt-users] Recommended Ovirt Implementation on Active-Active Datacenters (Site 1 and Site2) - Same Cluster
by Roy Golan 24 Nov '16

24 Nov '16

On Nov 24, 2016 5:01 PM, "Roy Golan" <rgolan(a)redhat.com> wrote: Reposting to list > Affinity labels [1] will allow you to label the hosts and vms to site1 and site2 and that should be it. > > - create label per site > - add the redpective label to each vm and host > > Unfortunately there is no UI for that but with SDK or rest it's easy > > [1] https://www.ovirt.org/blog/2016/07/affinity-labels/ > > > On Nov 24, 2016 3:12 PM, "Rogério Ceni Coelho" < rogeriocenicoelho(a)gmail.com> wrote: >> >> Hi Ovirt Jedi´s !!! >> >> First of all, congrats about the product !!! I love Ovirt !!! >> >> I am using Ovirt 4.0.4 with 10 hosts and 58 virtual machines on two Active-Active Datacenters using two EMC Vplex + two EMC VNX5500 + eight Dell Blades + 8 Dell PowerEdge M610 and two M620 Servers. >> >> Half servers are on Site 1 and Half servers on Site 2. The same with VMs. All Sites work as one and have redundant network, storage, power, etc etc etc ... >> >> I want to know what is the best way to set that VM number 1 runs on Site 1 and VM number 2 runs on Site 2 ? >> >> On Vmware 5.1 we use DRS Group Manager and on Hyper-V we use Custom Properties on hosts and on VMs. What we use on oVirt without segregate on two different Datacenters or two different clusters ? >> >> Thanks in advance. >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >>

1 0

master deps broken for el7
by Sandro Bonazzola 24 Nov '16

24 Nov '16

Hi, FYI, jenkins detected broken dependencies issues withing vdsm package. It seems that some package are missing so I'm rebuilding the repository. Some failures may happen in the next 45 minutes. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

When you 'select *' you actually use ~10% of the data
by Michal Skrivanek 24 Nov '16

24 Nov '16

reposting > On 23 Nov 2016, at 10:22, Arik Hadas <ahadas(a)redhat.com> wrote: > > +1 > And this should come as no surprise to one that read [1] - it shows that querying 6000 VMs that run on a particular host in the monitoring took 765.774 ms on 3.6 by querying the 'vms' view while on master the same task (on the same database) took 2.703 ms by querying only the dynamic VM data (vm_dynamic). > Following this result, we (virt) already replaced calls to queries that are based on the heavy 'vms' view with ones that call lighter queries that are based on 'vm_static' and 'vm_dynamic' in most of the core virt flows. We also introduced lighter query named 'vms_monitoring_view' that is already used in several places (and can be used even further) instead of 'vms'. This principle is recommended in other places and for other entities (where appropriate) as well. > > [1] http://www.ovirt.org/blog/2016/08/monitoring-improvements-in-ovirt/ > > ---- Original Message — > On Wed, Nov 23, 2016 at 10:34 AM, Roy Golan <rgolan(a)redhat.com> wrote: >> It turns our that our busiest UI grids, 'Vms', 'Hosts', 'Disks' are using >> fraction of the data they really need. Every time we load the tab, or >> refresh it we invoke a 'SearchQuery' which effectively is translated to >> 'SELECT * from VIEW LIMIT 100'. Our views contains HUGH amount of joins >> just to feed the monster while we don't need it at all. >> >> See this table to understand how far we got: >> >> Grid name | Grid column count | # of columns in view | # of joins in view >> >> Vms tab | 14 | 161 | 9 >> Hosts tab | 11 | 137 | 8 >> Disks | 9 | 58 | 9 >> >> >> The numbers are not precise cause few more fields are needed for internal >> logic probably but this is very close the actual num. The numbers of views >> involved may even be higher because some of the view are using... more views >> >> >> This is not UI specific. Tons of bll code uses the views entities just >> because >> its easy while working with tailoring a query to your needs would perform way >> better. We obviously need to STOP doing that and create code that will >> encourage >> us to do get just enough data we need. This is a debate about or dal >> layer and its >> relationship with stored procedure AND our coding guidelines with db >> interaction. >> >> I didn't measure the effec tof moving to specific queries and using the >> result >> but I'm pretty sure it's going to be dramatic. >> >> So please, as a start, stop using the views cause it's easy, prefer the >> tables and create >> procedure to support your data needs. >> >> >> I opened a bug for that to track that and will work on POC to measure the >> effect >> >> *Bug 1397691* <https://bugzilla.redhat.com/show_bug.cgi?id=1397691> - >> [scale] UI grids queries all fields while ~10% is actually needed >> > >

1 0

[ ERROR ] schema.sh: Please fix numbering to interval 04010491 to 04010500 and run the upgrade script.
by Sandro Bonazzola 24 Nov '16

24 Nov '16

engine master CI is failing on $subject, please fix or revert as soon as possible, thanks. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

7 13

snapshot merge failing on Experimental
by Evgheni Dereveanchin 24 Nov '16

24 Nov '16

Hi everyone, CI is failing on snapshot merge tests: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3618/testR… Not sure what is causing this but I see several patches that may be related that were recently merged: https://gerrit.ovirt.org/#/c/67064 https://gerrit.ovirt.org/#/c/67184 Could someone please check why it's happening as we need to fix/revert the problematic patch to make tests work again. Regards, Evgheni Dereveanchin

6 6

Restoring ovirt-release-master rpm
by Sandro Bonazzola 23 Nov '16

23 Nov '16

Looks like someone deleted ovirt-release-master rpm from http://resources.ovirt.org/pub/yum-repo/ breaking several stuff including website documentation. I'm restoring it, please avoid removing rpms without discussing it. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 2

Removal of xmlrpc
by Piotr Kliczewski 23 Nov '16

23 Nov '16

I am working on xmlrpc removal from the engine. I see bunch of references in [1] to xmlrpc client. Is there any reason why we need it? Do we plan to rewrite it to use other protocol? I am going to leave this code and xmlrpc dependency in the engine so we can improve it later. Thanks, Piotr [1] https://github.com/oVirt/ovirt-engine/blob/67880b549bada18aa3466d20a77da5c0…

2 1

Project ovirt-engine-api-model_4.0_build-artifacts-fc24-x86_64 is failing
by Sandro Bonazzola 23 Nov '16

23 Nov '16

http://jenkins.ovirt.org/job/ovirt-engine-api-model_4.0_build-artifacts-fc2… *00:04:35.993* + mv target/model.json exported-artifacts*00:04:35.993* mv: cannot stat 'target/model.json': No such file or directory*00:04:35.993* Took 93 seconds Can you please have a look? -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

3 6

[VDSM] FAIL: test_intra_domain_copy('block', 'cow', 'cow') (storage_sdm_copy_data_test.TestCopyDataDIV)
by Nir Soffer 22 Nov '16

22 Nov '16

This test pass usually, Adam, can you check this? 21:15:52 ====================================================================== 21:15:52 FAIL: test_intra_domain_copy('block', 'cow', 'cow') (storage_sdm_copy_data_test.TestCopyDataDIV) 21:15:52 ---------------------------------------------------------------------- 21:15:52 Traceback (most recent call last): 21:15:52 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/testlib.py", line 133, in wrapper 21:15:52 return f(self, *args) 21:15:52 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/storage_sdm_copy_data_test.py", line 138, in test_intra_domain_copy 21:15:52 self.assertEqual(100.0, job.progress) 21:15:52 AssertionError: 100.0 != 0.0 21:15:52 -------------------- >> begin captured logging << -------------------- 21:15:52 2016-11-16 21:14:26,096 DEBUG (MainThread) [storage.PersistentDict] Created a persistent dict with VGTagMetadataRW backend (persistent:194) 21:15:52 2016-11-16 21:14:26,096 DEBUG (MainThread) [storage.PersistentDict] read lines (VGTagMetadataRW)=[] (persistent:236) 21:15:52 2016-11-16 21:14:26,097 DEBUG (MainThread) [storage.PersistentDict] Empty metadata (persistent:254) 21:15:52 2016-11-16 21:14:26,097 DEBUG (MainThread) [storage.PersistentDict] Starting transaction (persistent:169) 21:15:52 2016-11-16 21:14:26,097 DEBUG (MainThread) [storage.PersistentDict] Flushing changes (persistent:175) 21:15:52 2016-11-16 21:14:26,097 DEBUG (MainThread) [storage.PersistentDict] about to write lines (VGTagMetadataRW)=['CLASS=Data', 'POOL_UUID=fb6edad8-51ab-4aad-9090-a833efd6a1e2', 'SDUUID=beb999a9-a90b-4c49-9d4c-7b21b3adb164', 'VERSION=3', '_SHA_CKSUM=63ec9e7bc3d23a7da8ef5e318fdd65203ac7c3fe'] (persistent:307) 21:15:52 2016-11-16 21:14:26,098 DEBUG (MainThread) [storage.Metadata.VGTagMetadataRW] Updating metadata adding=MDT__SHA_CKSUM=63ec9e7bc3d23a7da8ef5e318fdd65203ac7c3fe, MDT_VERSION=3, MDT_POOL_UUID=fb6edad8-51ab-4aad-9090-a833efd6a1e2, MDT_CLASS=Data, MDT_SDUUID=beb999a9-a90b-4c49-9d4c-7b21b3adb164 removing= (blockSD:296) 21:15:52 2016-11-16 21:14:26,098 DEBUG (MainThread) [storage.PersistentDict] Finished transaction (persistent:177) 21:15:52 2016-11-16 21:14:26,101 WARNING (MainThread) [storage.StorageDomainManifest] Could not find mapping for lv beb999a9-a90b-4c49-9d4c-7b21b3adb164/1b8476de-236b-4c8e-aea0-134b213b7cb7 (blockSD:786) 21:15:52 2016-11-16 21:14:26,101 DEBUG (MainThread) [storage.StorageDomainManifest] Found freeSlot 4 in VG beb999a9-a90b-4c49-9d4c-7b21b3adb164 (blockSD:759) 21:15:52 2016-11-16 21:14:26,103 DEBUG (MainThread) [storage.VolumeManifest] Creating symlink from /var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/1b8476de-236b-4c8e-aea0-134b213b7cb7 to /var/tmp/tmpKpf5ys/mnt/blockSD/beb999a9-a90b-4c49-9d4c-7b21b3adb164/images/c406fa29-72c8-4a26-9601-2bd5e0b1cbd0/1b8476de-236b-4c8e-aea0-134b213b7cb7 (blockVolume:147) 21:15:52 2016-11-16 21:14:26,103 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-3 /usr/bin/qemu-img create -f qcow2 -o compat=0.10 /var/tmp/tmpKpf5ys/mnt/blockSD/beb999a9-a90b-4c49-9d4c-7b21b3adb164/images/c406fa29-72c8-4a26-9601-2bd5e0b1cbd0/1b8476de-236b-4c8e-aea0-134b213b7cb7 1048576 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,144 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,148 WARNING (MainThread) [storage.StorageDomainManifest] Could not find mapping for lv beb999a9-a90b-4c49-9d4c-7b21b3adb164/0e7c49ae-6c7c-4526-89c2-17b923c70dfa (blockSD:786) 21:15:52 2016-11-16 21:14:26,148 DEBUG (MainThread) [storage.StorageDomainManifest] Found freeSlot 5 in VG beb999a9-a90b-4c49-9d4c-7b21b3adb164 (blockSD:759) 21:15:52 2016-11-16 21:14:26,149 DEBUG (MainThread) [storage.VolumeManifest] Creating symlink from /var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/0e7c49ae-6c7c-4526-89c2-17b923c70dfa to /var/tmp/tmpKpf5ys/mnt/blockSD/beb999a9-a90b-4c49-9d4c-7b21b3adb164/images/939d015f-e57e-4bf1-9013-b648fae347ae/0e7c49ae-6c7c-4526-89c2-17b923c70dfa (blockVolume:147) 21:15:52 2016-11-16 21:14:26,150 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-3 /usr/bin/qemu-img create -f qcow2 -o compat=0.10 /var/tmp/tmpKpf5ys/mnt/blockSD/beb999a9-a90b-4c49-9d4c-7b21b3adb164/images/939d015f-e57e-4bf1-9013-b648fae347ae/0e7c49ae-6c7c-4526-89c2-17b923c70dfa 1048576 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,195 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,196 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=4 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,207 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000394548 s, 1.3 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,208 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000394548 s, 1.3 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,209 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-3 qemu-io -f qcow2 -c 'write -P 240 0 1024' /var/tmp/tmpKpf5ys/mnt/blockSD/beb999a9-a90b-4c49-9d4c-7b21b3adb164/images/c406fa29-72c8-4a26-9601-2bd5e0b1cbd0/1b8476de-236b-4c8e-aea0-134b213b7cb7 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,257 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,260 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=5 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,274 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000359356 s, 1.4 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,274 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000359356 s, 1.4 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,275 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-3 qemu-io -f qcow2 -c 'read -P 240 -s 0 -l 1024 0 1024' /var/tmp/tmpKpf5ys/mnt/blockSD/beb999a9-a90b-4c49-9d4c-7b21b3adb164/images/939d015f-e57e-4bf1-9013-b648fae347ae/0e7c49ae-6c7c-4526-89c2-17b923c70dfa (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,316 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,318 INFO (MainThread) [root] Running job 'f8a60ab8-2ba9-473d-bf46-82080c283137'... (jobs:179) 21:15:52 2016-11-16 21:14:26,320 INFO (MainThread) [storage.VolumeManifest] Volume: preparing volume beb999a9-a90b-4c49-9d4c-7b21b3adb164/1b8476de-236b-4c8e-aea0-134b213b7cb7 (volume:462) 21:15:52 2016-11-16 21:14:26,321 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=4 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,335 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000302993 s, 1.7 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,336 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000302993 s, 1.7 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,338 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=4 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,351 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000368094 s, 1.4 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,352 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000368094 s, 1.4 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,354 INFO (MainThread) [storage.VolumeManifest] Volume: preparing volume beb999a9-a90b-4c49-9d4c-7b21b3adb164/0e7c49ae-6c7c-4526-89c2-17b923c70dfa (volume:462) 21:15:52 2016-11-16 21:14:26,355 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=5 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,368 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000382558 s, 1.3 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,369 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000382558 s, 1.3 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,370 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=5 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,388 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000326875 s, 1.6 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,389 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000326875 s, 1.6 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,391 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=5 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,404 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000335536 s, 1.5 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,405 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000335536 s, 1.5 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,406 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=4 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,420 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000292733 s, 1.7 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,421 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000292733 s, 1.7 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,422 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=4 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,436 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000359596 s, 1.4 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,437 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000359596 s, 1.4 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,438 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=4 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,451 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000322085 s, 1.6 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,452 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000322085 s, 1.6 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,454 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=5 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:15:52 2016-11-16 21:14:26,467 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.00033405 s, 1.5 MB/s\n'; <rc> = 0 (commands:93) 21:15:52 2016-11-16 21:14:26,468 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.00033405 s, 1.5 MB/s'], size: 512 (misc:138) 21:15:52 2016-11-16 21:14:26,469 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=5 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:16:08 2016-11-16 21:14:26,481 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.00030909 s, 1.7 MB/s\n'; <rc> = 0 (commands:93) 21:16:08 2016-11-16 21:14:26,482 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.00030909 s, 1.7 MB/s'], size: 512 (misc:138) 21:16:08 2016-11-16 21:14:26,483 INFO (MainThread) [storage.VolumeManifest] sdUUID=beb999a9-a90b-4c49-9d4c-7b21b3adb164 imgUUID=939d015f-e57e-4bf1-9013-b648fae347ae volUUID = 0e7c49ae-6c7c-4526-89c2-17b923c70dfa legality = ILLEGAL (volume:368) 21:16:08 2016-11-16 21:14:26,484 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=5 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:16:08 2016-11-16 21:14:26,497 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000307797 s, 1.7 MB/s\n'; <rc> = 0 (commands:93) 21:16:08 2016-11-16 21:14:26,498 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000307797 s, 1.7 MB/s'], size: 512 (misc:138) 21:16:08 2016-11-16 21:14:26,502 DEBUG (MainThread) [QemuImg] /usr/bin/taskset --cpu-list 0-3 /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /usr/bin/qemu-img convert -p -t none -T none -f qcow2 /var/tmp/tmpKpf5ys/mnt/blockSD/beb999a9-a90b-4c49-9d4c-7b21b3adb164/images/c406fa29-72c8-4a26-9601-2bd5e0b1cbd0/1b8476de-236b-4c8e-aea0-134b213b7cb7 -O qcow2 -o compat=0.10 /var/tmp/tmpKpf5ys/mnt/blockSD/beb999a9-a90b-4c49-9d4c-7b21b3adb164/images/939d015f-e57e-4bf1-9013-b648fae347ae/0e7c49ae-6c7c-4526-89c2-17b923c70dfa (cwd None) (qemuimg:247) 21:16:08 2016-11-16 21:14:26,805 DEBUG (MainThread) [storage.Misc.excCmd] /usr/bin/taskset --cpu-list 0-3 /usr/bin/dd iflag=direct skip=5 bs=512 if=/var/tmp/tmpKpf5ys/dev/beb999a9-a90b-4c49-9d4c-7b21b3adb164/metadata count=1 (cwd None) (commands:69) 21:16:08 2016-11-16 21:14:26,820 DEBUG (MainThread) [storage.Misc.excCmd] SUCCESS: <err> = '1+0 records in\n1+0 records out\n512 bytes copied, 0.000380116 s, 1.3 MB/s\n'; <rc> = 0 (commands:93) 21:16:08 2016-11-16 21:14:26,821 DEBUG (MainThread) [storage.Misc] err: ['1+0 records in', '1+0 records out', '512 bytes copied, 0.000380116 s, 1.3 MB/s'], size: 512 (misc:138) 21:16:08 2016-11-16 21:14:26,823 INFO (MainThread) [storage.VolumeManifest] Tearing down volume beb999a9-a90b-4c49-9d4c-7b21b3adb164/0e7c49ae-6c7c-4526-89c2-17b923c70dfa justme True (blockVolume:386) 21:16:08 2016-11-16 21:14:26,824 INFO (MainThread) [storage.VolumeManifest] Tearing down volume beb999a9-a90b-4c49-9d4c-7b21b3adb164/1b8476de-236b-4c8e-aea0-134b213b7cb7 justme True (blockVolume:386) 21:16:08 2016-11-16 21:14:26,824 INFO (MainThread) [root] Job 'f8a60ab8-2ba9-473d-bf46-82080c283137' completed (jobs:203) 21:16:08 2016-11-16 21:14:26,825 INFO (MainThread) [root] Job 'f8a60ab8-2ba9-473d-bf46-82080c283137' will be deleted in 3600 seconds (jobs:245) 21:16:08 --------------------- >> end captured logging << ---------------------

2 4

engine-setup failed on master on Centos 7
by Martin Perina 22 Nov '16

22 Nov '16

Hi, if you have recently tried to install master engine on Centos 7, you may have encountered following error during engine-setup: Failed to execute stage 'Misc configuration': Command '/usr/bin/ovirt-aaa-jdbc-tool' failed to execute This is currently tracked by [1] and it's caused by faulty slfj4 1.7.10 package in virt7-ovirt-common-candidate repository. We have untagged faulty package from the repository, but to fix the error you need to downgrade package version to slf4j 1.7.4 provided by Centos [2]. Sorry for inconvenience Martin Perina [1] https://bugzilla.redhat.com/show_bug.cgi?id=1394656 [2] http://mirror.centos.org/centos/7/os/x86_64/Packages/slf4j-1.7.4-3.el7.noar…

1 0

blockcommit and gluster network disk path
by Sahina Bose 22 Nov '16

22 Nov '16

Hi, I'm running into problems with blockcommit and gluster network disks - wanted to check how to pass path for network disks. How's the protocol and host parameters specified? For a backing volume chain as below, executing virsh blockcommit fioo5 vmstore/912d9062-3881-479b-a6e5-7b074a252cb6/images/27b0cbcb-4dfd-4eeb-8ab0-8fda54a6d8a4/027a3b37-77d4-4fa9-8173-b1fedba1176c --base vmstore/912d9062-3881-479b-a6e5-7b074a252cb6/images/27b0cbcb-4dfd-4eeb-8ab0-8fda54a6d8a4/d4c23ec6-20ce-4a2f-9b32-ca91e65a114a --top vmstore/912d9062-3881-479b-a6e5-7b074a252cb6/images/27b0cbcb-4dfd-4eeb-8ab0-8fda54a6d8a4/027a3b37-77d4-4fa9-8173-b1fedba1176c --verbose --wait gives "error: invalid argument: No device found for specified path". <disk type='network' device='disk' snapshot='no'> <driver name='qemu' type='qcow2' cache='none' error_policy='stop' io='threads'/> <source protocol='gluster' name='vmstore/912d9062-3881-47 9b-a6e5-7b074a252cb6/images/27b0cbcb-4dfd-4eeb-8ab0-8fda54a6 d8a4/027a3b37-77d4-4fa9-8173-b1fedba1176c'> <host name='10.70.37.28' port='0'/> </source> <backingStore type='network' index='1'> <format type='qcow2'/> <source protocol='gluster' name='vmstore/912d9062-3881-47 9b-a6e5-7b074a252cb6/images/27b0cbcb-4dfd-4eeb-8ab0-8fda54a6 d8a4/d4c23ec6-20ce-4a2f-9b32-ca91e65a114a'> <host name='10.70.37.28' port='0'/> </source> <backingStore type='network' index='2'> <format type='raw'/> <source protocol='gluster' name='vmstore/912d9062-3881-47 9b-a6e5-7b074a252cb6/images/27b0cbcb-4dfd-4eeb-8ab0-8fda54a6 d8a4/f5098809-e719-404b-8d80-3f824f4333a2'> <host name='10.70.37.28' port='0'/> </source> <backingStore/> </backingStore> </backingStore> <target dev='vda' bus='virtio'/> <serial>27b0cbcb-4dfd-4eeb-8ab0-8fda54a6d8a4</serial> <boot order='2'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk> thanks sahina

1 1

[Call for Vote] Proposal for new Incubator Project
by Brian Proffitt 22 Nov '16

22 Nov '16

All: This project was initially proposed for review on Oct. 9. It has been reviewed for major issues and having heard no objections, it's now time to formally vote on accepting this as an official oVirt incubator subproject. The last time we voted on one of these was during an IRC weekly meeting, so I believe it is appropriate to post a Call for Vote on the Devel and Board lists. Voting will be open until 1200 UTC Nov. 28, 2016. A net total of +5 votes should be received to formalize this project as an incubator subproject. Please use the following vote process: +1 Yes, agree, or the action should be performed. On some issues, this vote must only be given after the voter has tested the action on their own system(s). ±0 Abstain, no opinion, or I am happy to let the other group members decide this issue. An abstention may have detrimental affects if too many people abstain. -1 No, I veto this action. All vetos must include an explanation of why the veto is appropriate. A veto with no explanation is void. Thank you! Brian Proffitt --- Project Proposal - Vagrant Provider A vagrant provider for oVirt v4 Abstract This will be a provider plugin for the Vagrant suite that allows command-line ease of virtual machine provisioning and lifecycle management. Proposal This Vagrant provider plugin will interface with the oVirt REST API (version 4 and higher) using the oVirt provided ruby SDK 'ovirt-engine-sdk-ruby'. This allows users to abstract the user interface and experience into a set of command line abilities to create, provision, destroy and manage the complete lifecycle of virtual machines. It also allows the use of external configuration management and configuration files themselves to be committed into code. Background I have previously forked and maintained the 'vagrant-ovirt' gem as 'vagrant-ovirt3' due to Gems requiring unique names. The original author has officially abandoned the project. For the last few years all code to maintain this project has been maintained by myself and a few ad-hoc github contributors. This provider interfaced directly with oVirt v3 using fog and rbovirt. The new project would be a fresh start using the oVirt provided ruby SDK to work directly with version 4. Rationale The trend in configuration management, operations, and devops has been to maintain as much of the development process as possible in terms of the virtual machines and hosts that they run on. With software like Terraform the tasks of creating the underlying infrastructure such as network rules, etc have had great success moving into 'Infrastructure as code'. The same company behind Terraform got their reputation from Vagrant which aims to utilize the same process for virtual machines themselves. The core software allows for standard commands such as 'up', 'provision', 'destroy' to be used across a provider framework. A provider for oVirt makes the process for managing VMs easier and able to be controlled through code and source control. Initial Goals The initial goal is to get the base steps of 'up', 'down' (halt), and 'destroy' to succeed using the oVirt provided ruby SDK for v4. Stretch/followup goals would be to ensure testability and alternate commands such as 'provision' and allow configuration management suites like puppet to work via 'userdata' (cloud-init). Current Status The version 3 of this software has been heavily utilized. The original fork known as 'vagrant-ovirt' has been abandoned with no plans to communicate or move forward. My upstream fork has had great success with nearly 4x the downloads from rubygems.org . Until my github fork has more 'stars' I cannot take over it completely so the gem was renamed 'vagrant-ovirt3'. This is also true for rubygems.org since gems are not namespaced, therefore could not be published without a unique name. The v4 provider is still pending my initial POC commit but there are no current barriers except initial oVirt hosting. The hosting of oVirt v3 for testing is a laptop on a UPS at my home, and v4 is also a different pc attached to a UPS. External Dependencies RHEVM/oVirt REST API - This provider must interact with the API itself to manage virtual machines. Initial Committers Marcus Young ( 3vilpenguin at gmail dot com ) -- Brian Proffitt Principal Community Analyst Open Source and Standards @TheTechScribe 574.383.9BKP

15 14

Fwd: New Defects reported by Coverity Scan for ovirt-engine
by Michal Skrivanek 21 Nov '16

21 Nov '16

--Apple-Mail-D6BD3946-3D96-44AC-A6CA-27DF220B7C24 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Not sure who touched that, but since it's a NPE - Tal, can you doublecheck p= lease? Begin forwarded message: > From: scan-admin(a)coverity.com > Date: 21 November 2016 at 21:13:22 GMT+1 > To: mskrivan(a)redhat.com > Subject: New Defects reported by Coverity Scan for ovirt-engine >=20 >=20 > Hi, >=20 > Please find the latest report on new defect(s) introduced to ovirt-engine f= ound with Coverity Scan. >=20 > 2 new defect(s) introduced to ovirt-engine found with Coverity Scan. > 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the r= ecent build analyzed by Coverity Scan. >=20 > New defect(s) Reported-by: Coverity Scan > Showing 2 of 2 defect(s) >=20 >=20 > ** CID 1366189: Null pointer dereferences (NULL_RETURNS) > /backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vds= broker/vdsbroker/GetDeviceListVDSCommand.java: 112 in org.ovirt.engine.core.= vdsbroker.vdsbroker.GetDeviceListVDSCommand.parseLunFromXmlRpc(java.util.Map= , org.ovirt.engine.core.compat.Version)() >=20 >=20 > __________________________________________________________________________= ______________________________ > *** CID 1366189: Null pointer dereferences (NULL_RETURNS) > /backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vds= broker/vdsbroker/GetDeviceListVDSCommand.java: 112 in org.ovirt.engine.core.= vdsbroker.vdsbroker.GetDeviceListVDSCommand.parseLunFromXmlRpc(java.util.Map= , org.ovirt.engine.core.compat.Version)() > 106 .put(xcon.get(PHYSICAL_DEVICE_FIEL= D).toString(), > 107 DEVICE_ACTIVE_VALUE.equals= (xcon.get(DEVICE_STATE_FIELD).toString())); > 108 } > 109 if (xcon.containsKey(PHYSICAL_DEVICE_FIELD) &&= xcon.containsKey(DEVICE_PATH_CAPACITY_FIELD)) { > 110 // set name and capacity > 111 Long size =3D IrsBrokerCommand.assignLongV= alue(xcon, DEVICE_PATH_CAPACITY_FIELD); >>>> CID 1366189: Null pointer dereferences (NULL_RETURNS) >>>> Unboxing null object "size". > 112 lun.getPathsCapacity() > 113 .put(xcon.get(PHYSICAL_DEVICE_FIEL= D).toString(), > 114 SizeConverter.convert(size= , > 115 SizeConverter.Size= Unit.BYTES, SizeConverter.SizeUnit.GiB).intValue()); > 116 } > 117 } >=20 > ** CID 1366190: Resource leaks (RESOURCE_LEAK) > /backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/stora= ge/CommandsWeightsUtilsTest.java: 37 in org.ovirt.engine.core.bll.storage.Co= mmandsWeightsUtilsTest.adjustWeights(java.util.List, java.util.List, int)() >=20 >=20 > __________________________________________________________________________= ______________________________ > *** CID 1366190: Resource leaks (RESOURCE_LEAK) > /backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/stora= ge/CommandsWeightsUtilsTest.java: 37 in org.ovirt.engine.core.bll.storage.Co= mmandsWeightsUtilsTest.adjustWeights(java.util.List, java.util.List, int)() > 31 adjustWeights(Arrays.<Double> asList(0.33, 0.37, 0.3), Arra= ys.<Integer> asList(3, 3, 4), 10); > 32 } > 33 =20 > 34 public void adjustWeights(List<Double> weightParts, List<Intege= r> expectedWeightsSorted, int totalWeight) { > 35 assertFalse(weightsUtils =3D=3D null); > 36 Map<String, Double> map =3D new HashMap<>(); >>>> CID 1366190: Resource leaks (RESOURCE_LEAK) >>>> Failing to save or close resource created by "java.util.stream.IntSt= ream.range(0, weightParts.size())" leaks it. > 37 IntStream.range(0, weightParts.size()).forEach(i -> map.put= (String.valueOf(i), weightParts.get(i))); > 38 Map<String, Integer> res =3D weightsUtils.adjust(map, total= Weight); > 39 assertEquals("adjusted weights sum should be equal to the t= otal weight", > 40 totalWeight, > 41 res.values().stream().mapToInt(x -> x).sum()); > 42 =20 >=20 >=20 > __________________________________________________________________________= ______________________________ > To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.n= et/wf/click?upn=3D08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRY9v3SZ-2= BLqhn66fucWz5NChdV2QNZzLQCPY1fjqQGlAKjFKQ4pnDnQ8dtAwvCE2G0E-3D_xDvy9aTtFVlNg= NTFLiCVD0cicL2K6Y3d-2BJIBr-2FpAeMq2Gor5C1ZEiQuot3av2-2FBnTXIjnZdjb0Cw-2FiZV5= z3DRotm2ow-2BiwdoVplKeuk7nRFrRXzS4jJb3IZXBSxeZC0bc8KPnuElHCtQryUJ5u-2FY6QjMU= nZuFDu-2BC21coRtHfPr1uF9ZCvkTQAT-2Bg5drHSbNPaszp0YnZzvaUGArGUlXQkPt48dc-2FNZ= aixgGomwsPPQ-3D >=20 > To manage Coverity Scan email notifications for "mskrivan(a)redhat.com", cli= ck https://u2389337.ct.sendgrid.net/wf/click?upn=3D08onrYu34A-2BWcWUl-2F-2Bf= V0V05UPxvVjWch-2Bd2MGckcRbVDbis712qZDP-2FA8y06Nq4QYNJdvz3-2Bo6D7kzKGM4BieGXc= FZeVj8bblbpPZS135zo-2F9pagiHHlVMtL1t-2BQNkdMMpi2fcAFj8yWlY6sxZhzNUWHvSkeP6Ld= DHUGDSs8PI-3D_xDvy9aTtFVlNgNTFLiCVD0cicL2K6Y3d-2BJIBr-2FpAeMq2Gor5C1ZEiQuot3= av2-2FBnYwmACJZZa-2BkRa13JTRgm4K6JnogNoqDZTzNvLRxP6Val1P03EDtJ3QxTG8urJ-2FCT= uXNzEDZ24au9cRqVgy9YVPOiVSvw7tAY4dzssRc8ERmy1mCzlCbU6-2B9s01kYf0EYko6e7QKj2V= pVxVJD8bRNr-2FNXcUSv-2Bu1fA612id1LcCM-3D >=20 --Apple-Mail-D6BD3946-3D96-44AC-A6CA-27DF220B7C24 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+PC9kaXY+ PGRpdj5Ob3Qgc3VyZSB3aG8gdG91Y2hlZCB0aGF0LCBidXQgc2luY2UgaXQncyBhIE5QRSAtIFRh bCwgY2FuIHlvdSBkb3VibGVjaGVjayBwbGVhc2U/PGJyPjxicj48YnI+QmVnaW4gZm9yd2FyZGVk IG1lc3NhZ2U6PGJyPjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxiPkZy b206PC9iPiA8YSBocmVmPSJtYWlsdG86c2Nhbi1hZG1pbkBjb3Zlcml0eS5jb20iPnNjYW4tYWRt aW5AY292ZXJpdHkuY29tPC9hPjxicj48Yj5EYXRlOjwvYj4gMjEgTm92ZW1iZXIgMjAxNiBhdCAy MToxMzoyMiBHTVQrMTxicj48Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzptc2tyaXZhbkByZWRo YXQuY29tIj5tc2tyaXZhbkByZWRoYXQuY29tPC9hPjxicj48Yj5TdWJqZWN0OjwvYj4gPGI+TmV3 IERlZmVjdHMgcmVwb3J0ZWQgYnkgQ292ZXJpdHkgU2NhbiBmb3Igb3ZpcnQtZW5naW5lPC9iPjxi cj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PHNw YW4+PC9zcGFuPjxicj48c3Bhbj5IaSw8L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+ UGxlYXNlIGZpbmQgdGhlIGxhdGVzdCByZXBvcnQgb24gbmV3IGRlZmVjdChzKSBpbnRyb2R1Y2Vk IHRvIG92aXJ0LWVuZ2luZSBmb3VuZCB3aXRoIENvdmVyaXR5IFNjYW4uPC9zcGFuPjxicj48c3Bh bj48L3NwYW4+PGJyPjxzcGFuPjIgbmV3IGRlZmVjdChzKSBpbnRyb2R1Y2VkIHRvIG92aXJ0LWVu Z2luZSBmb3VuZCB3aXRoIENvdmVyaXR5IFNjYW4uPC9zcGFuPjxicj48c3Bhbj4xIGRlZmVjdChz KSwgcmVwb3J0ZWQgYnkgQ292ZXJpdHkgU2NhbiBlYXJsaWVyLCB3ZXJlIG1hcmtlZCBmaXhlZCBp biB0aGUgcmVjZW50IGJ1aWxkIGFuYWx5emVkIGJ5IENvdmVyaXR5IFNjYW4uPC9zcGFuPjxicj48 c3Bhbj48L3NwYW4+PGJyPjxzcGFuPk5ldyBkZWZlY3QocykgUmVwb3J0ZWQtYnk6IENvdmVyaXR5 IFNjYW48L3NwYW4+PGJyPjxzcGFuPlNob3dpbmcgMiBvZiAyIGRlZmVjdChzKTwvc3Bhbj48YnI+ PHNwYW4+PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPioqIENJRCAxMzY2MTg5OiAm bmJzcDtOdWxsIHBvaW50ZXIgZGVyZWZlcmVuY2VzICZuYnNwOyhOVUxMX1JFVFVSTlMpPC9zcGFu Pjxicj48c3Bhbj4vYmFja2VuZC9tYW5hZ2VyL21vZHVsZXMvdmRzYnJva2VyL3NyYy9tYWluL2ph dmEvb3JnL292aXJ0L2VuZ2luZS9jb3JlL3Zkc2Jyb2tlci92ZHNicm9rZXIvR2V0RGV2aWNlTGlz dFZEU0NvbW1hbmQuamF2YTogMTEyIGluIG9yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIu dmRzYnJva2VyLkdldERldmljZUxpc3RWRFNDb21tYW5kLnBhcnNlTHVuRnJvbVhtbFJwYyhqYXZh LnV0aWwuTWFwLCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuY29tcGF0LlZlcnNpb24pKCk8L3NwYW4+ PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+PHNwYW4+KioqIENJ RCAxMzY2MTg5OiAmbmJzcDtOdWxsIHBvaW50ZXIgZGVyZWZlcmVuY2VzICZuYnNwOyhOVUxMX1JF VFVSTlMpPC9zcGFuPjxicj48c3Bhbj4vYmFja2VuZC9tYW5hZ2VyL21vZHVsZXMvdmRzYnJva2Vy L3NyYy9tYWluL2phdmEvb3JnL292aXJ0L2VuZ2luZS9jb3JlL3Zkc2Jyb2tlci92ZHNicm9rZXIv R2V0RGV2aWNlTGlzdFZEU0NvbW1hbmQuamF2YTogMTEyIGluIG9yZy5vdmlydC5lbmdpbmUuY29y ZS52ZHNicm9rZXIudmRzYnJva2VyLkdldERldmljZUxpc3RWRFNDb21tYW5kLnBhcnNlTHVuRnJv bVhtbFJwYyhqYXZhLnV0aWwuTWFwLCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuY29tcGF0LlZlcnNp b24pKCk8L3NwYW4+PGJyPjxzcGFuPjEwNiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsucHV0KHhjb24uZ2V0KFBIWVNJQ0FMX0RFVklDRV9GSUVMRCkudG9TdHJp bmcoKSw8L3NwYW4+PGJyPjxzcGFuPjEwNyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtERVZJQ0VfQUNUSVZFX1ZBTFVFLmVxdWFscyh4Y29uLmdldChERVZJQ0VfU1RBVEVfRklF TEQpLnRvU3RyaW5nKCkpKTs8L3NwYW4+PGJyPjxzcGFuPjEwOCAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDt9PC9zcGFuPjxicj48c3Bhbj4xMDkgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7aWYgKHhjb24uY29udGFpbnNLZXkoUEhZU0lDQUxfREVWSUNFX0ZJRUxEKSAmYW1wOyZh bXA7IHhjb24uY29udGFpbnNLZXkoREVWSUNFX1BBVEhfQ0FQQUNJVFlfRklFTEQpKSB7PC9zcGFu Pjxicj48c3Bhbj4xMTAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Ly8gc2V0IG5hbWUgYW5kIGNhcGFjaXR5PC9zcGFuPjxicj48c3Bhbj4xMTEg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7TG9u ZyBzaXplID0gSXJzQnJva2VyQ29tbWFuZC5hc3NpZ25Mb25nVmFsdWUoeGNvbiwgREVWSUNFX1BB VEhfQ0FQQUNJVFlfRklFTEQpOzwvc3Bhbj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ICZuYnNw OyZuYnNwOyZuYnNwO0NJRCAxMzY2MTg5OiAmbmJzcDtOdWxsIHBvaW50ZXIgZGVyZWZlcmVuY2Vz ICZuYnNwOyhOVUxMX1JFVFVSTlMpPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3Rl PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJj aXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4gJm5ic3A7Jm5ic3A7Jm5ic3A7VW5i b3hpbmcgbnVsbCBvYmplY3QgInNpemUiLjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2tx dW90ZT48L2Jsb2NrcXVvdGU+PHNwYW4+MTEyICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2x1bi5nZXRQYXRoc0NhcGFjaXR5KCk8L3NwYW4+PGJy PjxzcGFuPjExMyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsu cHV0KHhjb24uZ2V0KFBIWVNJQ0FMX0RFVklDRV9GSUVMRCkudG9TdHJpbmcoKSw8L3NwYW4+PGJy PjxzcGFuPjExNCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtTaXplQ29udmVy dGVyLmNvbnZlcnQoc2l6ZSw8L3NwYW4+PGJyPjxzcGFuPjExNSAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtTaXplQ29udmVydGVyLlNpemVVbml0LkJZVEVTLCBTaXplQ29udmVydGVyLlNpemVV bml0LkdpQikuaW50VmFsdWUoKSk7PC9zcGFuPjxicj48c3Bhbj4xMTYgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7fTwvc3Bhbj48YnI+PHNwYW4+MTE3ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO308L3NwYW4+PGJyPjxz cGFuPjwvc3Bhbj48YnI+PHNwYW4+KiogQ0lEIDEzNjYxOTA6ICZuYnNwO1Jlc291cmNlIGxlYWtz ICZuYnNwOyhSRVNPVVJDRV9MRUFLKTwvc3Bhbj48YnI+PHNwYW4+L2JhY2tlbmQvbWFuYWdlci9t b2R1bGVzL2JsbC9zcmMvdGVzdC9qYXZhL29yZy9vdmlydC9lbmdpbmUvY29yZS9ibGwvc3RvcmFn ZS9Db21tYW5kc1dlaWdodHNVdGlsc1Rlc3QuamF2YTogMzcgaW4gb3JnLm92aXJ0LmVuZ2luZS5j b3JlLmJsbC5zdG9yYWdlLkNvbW1hbmRzV2VpZ2h0c1V0aWxzVGVzdC5hZGp1c3RXZWlnaHRzKGph dmEudXRpbC5MaXN0LCBqYXZhLnV0aWwuTGlzdCwgaW50KSgpPC9zcGFuPjxicj48c3Bhbj48L3Nw YW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPjxzcGFuPioqKiBDSUQgMTM2NjE5MDogJm5i c3A7UmVzb3VyY2UgbGVha3MgJm5ic3A7KFJFU09VUkNFX0xFQUspPC9zcGFuPjxicj48c3Bhbj4v YmFja2VuZC9tYW5hZ2VyL21vZHVsZXMvYmxsL3NyYy90ZXN0L2phdmEvb3JnL292aXJ0L2VuZ2lu ZS9jb3JlL2JsbC9zdG9yYWdlL0NvbW1hbmRzV2VpZ2h0c1V0aWxzVGVzdC5qYXZhOiAzNyBpbiBv cmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLnN0b3JhZ2UuQ29tbWFuZHNXZWlnaHRzVXRpbHNUZXN0 LmFkanVzdFdlaWdodHMoamF2YS51dGlsLkxpc3QsIGphdmEudXRpbC5MaXN0LCBpbnQpKCk8L3Nw YW4+PGJyPjxzcGFuPjMxICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2FkanVzdFdlaWdodHMoQXJyYXlzLiZsdDtE b3VibGUmZ3Q7IGFzTGlzdCgwLjMzLCAwLjM3LCAwLjMpLCBBcnJheXMuJmx0O0ludGVnZXImZ3Q7 IGFzTGlzdCgzLCAzLCA0KSwgMTApOzwvc3Bhbj48YnI+PHNwYW4+MzIgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fTwvc3Bhbj48YnI+PHNwYW4+MzMgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxicj48c3Bhbj4zNCAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwdWJsaWMgdm9pZCBhZGp1c3RXZWlnaHRz KExpc3QmbHQ7RG91YmxlJmd0OyB3ZWlnaHRQYXJ0cywgTGlzdCZsdDtJbnRlZ2VyJmd0OyBleHBl Y3RlZFdlaWdodHNTb3J0ZWQsIGludCB0b3RhbFdlaWdodCkgezwvc3Bhbj48YnI+PHNwYW4+MzUg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7YXNzZXJ0RmFsc2Uod2VpZ2h0c1V0aWxzID09IG51bGwpOzwvc3Bhbj48 YnI+PHNwYW4+MzYgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7TWFwJmx0O1N0cmluZywgRG91YmxlJmd0OyBtYXAg PSBuZXcgSGFzaE1hcCZsdDsmZ3Q7KCk7PC9zcGFuPjxicj48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4g Jm5ic3A7Jm5ic3A7Jm5ic3A7Q0lEIDEzNjYxOTA6ICZuYnNwO1Jlc291cmNlIGxlYWtzICZuYnNw OyhSRVNPVVJDRV9MRUFLKTwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48L2Js b2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ICZuYnNwOyZuYnNwOyZuYnNwO0ZhaWxpbmcg dG8gc2F2ZSBvciBjbG9zZSByZXNvdXJjZSBjcmVhdGVkIGJ5ICJqYXZhLnV0aWwuc3RyZWFtLklu dFN0cmVhbS5yYW5nZSgwLCB3ZWlnaHRQYXJ0cy5zaXplKCkpIiBsZWFrcyBpdC48L3NwYW4+PGJy PjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxzcGFuPjM3ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO0ludFN0cmVhbS5yYW5nZSgwLCB3ZWlnaHRQYXJ0cy5zaXplKCkpLmZvckVhY2goaSAt Jmd0OyBtYXAucHV0KFN0cmluZy52YWx1ZU9mKGkpLCB3ZWlnaHRQYXJ0cy5nZXQoaSkpKTs8L3Nw YW4+PGJyPjxzcGFuPjM4ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO01hcCZsdDtTdHJpbmcsIEludGVnZXImZ3Q7 IHJlcyA9IHdlaWdodHNVdGlscy5hZGp1c3QobWFwLCB0b3RhbFdlaWdodCk7PC9zcGFuPjxicj48 c3Bhbj4zOSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthc3NlcnRFcXVhbHMoImFkanVzdGVkIHdlaWdodHMgc3Vt IHNob3VsZCBiZSBlcXVhbCB0byB0aGUgdG90YWwgd2VpZ2h0Iiw8L3NwYW4+PGJyPjxzcGFuPjQw ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO3RvdGFsV2VpZ2h0LDwvc3Bhbj48YnI+PHNwYW4+NDEgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVzLnZhbHVlcygp LnN0cmVhbSgpLm1hcFRvSW50KHggLSZndDsgeCkuc3VtKCkpOzwvc3Bhbj48YnI+PHNwYW4+NDIg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFu Pjwvc3Bhbj48YnI+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188L3NwYW4+PGJyPjxzcGFuPlRvIHZpZXcgdGhlIGRlZmVjdHMgaW4gQ292ZXJpdHkg U2NhbiB2aXNpdCwgPGEgaHJlZj0iaHR0cHM6Ly91MjM4OTMzNy5jdC5zZW5kZ3JpZC5uZXQvd2Yv Y2xpY2s/dXBuPTA4b25yWXUzNEEtMkJXY1dVbC0yRi0yQmZWMFYwNVVQeHZWaldjaC0yQmQyTUdj a2NSWTl2M1NaLTJCTHFobjY2ZnVjV3o1TkNoZFYyUU5aekxRQ1BZMWZqcVFHbEFLakZLUTRwbkRu UThkdEF3dkNFMkcwRS0zRF94RHZ5OWFUdEZWbE5nTlRGTGlDVkQwY2ljTDJLNlkzZC0yQkpJQnIt MkZwQWVNcTJHb3I1QzFaRWlRdW90M2F2Mi0yRkJuVFhJam5aZGpiMEN3LTJGaVpWNXozRFJvdG0y b3ctMkJpd2RvVnBsS2V1azduUkZyUlh6UzRqSmIzSVpYQlN4ZVpDMGJjOEtQbnVFbEhDdFFyeVVK NXUtMkZZNlFqTVVuWnVGRHUtMkJDMjFjb1J0SGZQcjF1RjlaQ3ZrVFFBVC0yQmc1ZHJIU2JOUGFz enAwWW5aenZhVUdBckdVbFhRa1B0NDhkYy0yRk5aYWl4Z0dvbXdzUFBRLTNEIj5odHRwczovL3Uy Mzg5MzM3LmN0LnNlbmRncmlkLm5ldC93Zi9jbGljaz91cG49MDhvbnJZdTM0QS0yQldjV1VsLTJG LTJCZlYwVjA1VVB4dlZqV2NoLTJCZDJNR2NrY1JZOXYzU1otMkJMcWhuNjZmdWNXejVOQ2hkVjJR Tlp6TFFDUFkxZmpxUUdsQUtqRktRNHBuRG5ROGR0QXd2Q0UyRzBFLTNEX3hEdnk5YVR0RlZsTmdO VEZMaUNWRDBjaWNMMks2WTNkLTJCSklCci0yRnBBZU1xMkdvcjVDMVpFaVF1b3QzYXYyLTJGQm5U WElqblpkamIwQ3ctMkZpWlY1ejNEUm90bTJvdy0yQml3ZG9WcGxLZXVrN25SRnJSWHpTNGpKYjNJ WlhCU3hlWkMwYmM4S1BudUVsSEN0UXJ5VUo1dS0yRlk2UWpNVW5adUZEdS0yQkMyMWNvUnRIZlBy MXVGOVpDdmtUUUFULTJCZzVkckhTYk5QYXN6cDBZblp6dmFVR0FyR1VsWFFrUHQ0OGRjLTJGTlph aXhnR29td3NQUFEtM0Q8L2E+PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPlRvIG1h bmFnZSBDb3Zlcml0eSBTY2FuIGVtYWlsIG5vdGlmaWNhdGlvbnMgZm9yICI8YSBocmVmPSJtYWls dG86bXNrcml2YW5AcmVkaGF0LmNvbSI+bXNrcml2YW5AcmVkaGF0LmNvbTwvYT4iLCBjbGljayA8 YSBocmVmPSJodHRwczovL3UyMzg5MzM3LmN0LnNlbmRncmlkLm5ldC93Zi9jbGljaz91cG49MDhv bnJZdTM0QS0yQldjV1VsLTJGLTJCZlYwVjA1VVB4dlZqV2NoLTJCZDJNR2NrY1JiVkRiaXM3MTJx WkRQLTJGQTh5MDZOcTRRWU5KZHZ6My0yQm82RDdrektHTTRCaWVHWGNGWmVWajhiYmxicFBaUzEz NXpvLTJGOXBhZ2lISGxWTXRMMXQtMkJRTmtkTU1waTJmY0FGajh5V2xZNnN4Wmh6TlVXSHZTa2VQ NkxkREhVR0RTczhQSS0zRF94RHZ5OWFUdEZWbE5nTlRGTGlDVkQwY2ljTDJLNlkzZC0yQkpJQnIt MkZwQWVNcTJHb3I1QzFaRWlRdW90M2F2Mi0yRkJuWXdtQUNKWlphLTJCa1JhMTNKVFJnbTRLNkpu b2dOb3FEWlR6TnZMUnhQNlZhbDFQMDNFRHRKM1F4VEc4dXJKLTJGQ1R1WE56RURaMjRhdTljUnFW Z3k5WVZQT2lWU3Z3N3RBWTRkenNzUmM4RVJteTFtQ3psQ2JVNi0yQjlzMDFrWWYwRVlrbzZlN1FL ajJWcFZ4VkpEOGJSTnItMkZOWGNVU3YtMkJ1MWZBNjEyaWQxTGNDTS0zRCI+aHR0cHM6Ly91MjM4 OTMzNy5jdC5zZW5kZ3JpZC5uZXQvd2YvY2xpY2s/dXBuPTA4b25yWXUzNEEtMkJXY1dVbC0yRi0y QmZWMFYwNVVQeHZWaldjaC0yQmQyTUdja2NSYlZEYmlzNzEycVpEUC0yRkE4eTA2TnE0UVlOSmR2 ejMtMkJvNkQ3a3pLR000QmllR1hjRlplVmo4YmJsYnBQWlMxMzV6by0yRjlwYWdpSEhsVk10TDF0 LTJCUU5rZE1NcGkyZmNBRmo4eVdsWTZzeFpoek5VV0h2U2tlUDZMZERIVUdEU3M4UEktM0RfeER2 eTlhVHRGVmxOZ05URkxpQ1ZEMGNpY0wySzZZM2QtMkJKSUJyLTJGcEFlTXEyR29yNUMxWkVpUXVv dDNhdjItMkZCbll3bUFDSlpaYS0yQmtSYTEzSlRSZ200SzZKbm9nTm9xRFpUek52TFJ4UDZWYWwx UDAzRUR0SjNReFRHOHVySi0yRkNUdVhOekVEWjI0YXU5Y1JxVmd5OVlWUE9pVlN2dzd0QVk0ZHpz c1JjOEVSbXkxbUN6bENiVTYtMkI5czAxa1lmMEVZa282ZTdRS2oyVnBWeFZKRDhiUk5yLTJGTlhj VVN2LTJCdTFmQTYxMmlkMUxjQ00tM0Q8L2E+PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjwv ZGl2PjwvYmxvY2txdW90ZT48L2JvZHk+PC9odG1sPg== --Apple-Mail-D6BD3946-3D96-44AC-A6CA-27DF220B7C24--

1 0

oVirt 4.0.6 RC2 build planned
by Sandro Bonazzola 21 Nov '16

21 Nov '16

Fyi oVirt developers, An oVirt build is planned for this Tuesday 10:00 AM TLV time (9:00 AM CET). Taking into consideration the time it takes for Jenkins to run a full CI everything need to be backported by Monday 11PM. Please make sure to mark as verified and CR +2 so it will be ready for merging Tuesday morning. A list of pending blockers is available here: https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.… -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 1

oVirt 4.0.6 RC2 merge / branch / tag / bugzilla reminder
by Sandro Bonazzola 21 Nov '16

21 Nov '16

All stable branch maintainers, please make sure to merge all relevant open bugs until Wednesday morning 10:00 AM TLV time (9:00 AM CET). For each package that need to be built (i.e oVirt product) please make sure every bug in MODIFIED has the right Target Release and Target Milestone. A Target release should state the version of the package you're building and should include the same version you used for the tag you just used for this build. (e.g. for ovirt-engine, tag: ovirt-engine-4.0.6, tr: 4.0.6) A list of bugs that require attention is here: https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.… -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Merge gating in Gerrit
by Barak Korren 21 Nov '16

21 Nov '16

Hi all, Perhaps the main purpose of CI, is to prevent braking code from getting merged into the stable/master branches. Unfortunately our CI is not there yet, and one of the reasons for that is that we do large amount of our CI tests only _after_ the code is merged. The reason for that is that when balancing through, but time consuming, tests (e.g. enging build with all permutations) v.s. faster but more basic ones (e.g. "findbugs" and single permutation build), we typically choose the faster tests to be run per-patch-set and leave the through testing to only be run post-merge. We'd like to change that and have the through tests also run before merge. Ideally we would like to just hook stuff to the "submit" button, but Gerrit doesn't allow one to do that easily. So instead we'll need to adopt some kind of flag to indicate we want to submit and have Jenkins "click" the submit button on our behalf if tests pass. I see two options here: 1. Use Code-Review+2 as the indicator to run "heavy" CI and merge. 2. Add an "approve" flag that maintainers can set to +1 (This is what OpenStack is doing). What would you prefer? -- Barak Korren bkorren(a)redhat.com RHEV-CI Team

7 10

system tests failing on template export
by Evgheni Dereveanchin 20 Nov '16

20 Nov '16

Hello, We've got several cases today where system tests failed when attempting to export templates: http://jenkins.ovirt.org/job/ovirt_master_system-tests/655/testReport/junit… Related engine.log looks something like this: https://paste.fedoraproject.org/449936/47643643/raw/ I could not find any obvious issues in SPM logs, could someone please take a look to confirm what may be causing this issue? Full logs from the test are available here: http://jenkins.ovirt.org/job/ovirt_master_system-tests/655/artifact/ Regards, Evgheni Dereveanchin

6 7

Failures in OST (4.0/master) ( was error msg from Jenkins )
by Eyal Edri 20 Nov '16

20 Nov '16

Renaming title and adding devel. On Sun, Nov 20, 2016 at 2:36 PM, Piotr Kliczewski <pkliczew(a)redhat.com> wrote: > The last failure seems to be storage related. > > @Nir please take a look. > > Here is engine side error: > > 2016-11-20 05:54:59,605 DEBUG [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand] > (default task-5) [59fc0074] Exception: org.ovirt.engine.core. > vdsbroker.irsbroker.IRSNoMasterDomainException: IRSGenericException: > IRSErrorException: IRSNoMasterDomainException: Cannot find master domain: > u'spUUID=1ca141f1-b64d-4a52-8861-05c7de2a72b2, msdUUID=7d4bf750-4fb8-463f- > bbb0-92156c47306e' > > and here is vdsm: > > jsonrpc.Executor/5::ERROR::2016-11-20 05:54:56,331::multipath::95:: > Storage.Multipath::(resize_devices) Could not resize device > 360014052749733c7b8248628637b990f > Traceback (most recent call last): > File "/usr/share/vdsm/storage/multipath.py", line 93, in resize_devices > _resize_if_needed(guid) > File "/usr/share/vdsm/storage/multipath.py", line 101, in > _resize_if_needed > for slave in devicemapper.getSlaves(name)] > File "/usr/share/vdsm/storage/multipath.py", line 158, in getDeviceSize > bs, phyBs = getDeviceBlockSizes(devName) > File "/usr/share/vdsm/storage/multipath.py", line 150, in > getDeviceBlockSizes > "queue", "logical_block_size")).read()) > IOError: [Errno 2] No such file or directory: > '/sys/block/sdb/queue/logical_block_size' > We now see a different error in master [1], which also indicates the hosts are in a problematic state: ( failing 'assign_hosts_network_label' test ) status: 409 reason: Conflict detail: Cannot add Label. Operation can be performed only when Host status is Maintenance, Up, NonOperational. -------------------- >> begin captured logging << -------------------- [1] http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/3506/testR… > > > On Sun, Nov 20, 2016 at 12:50 PM, Eyal Edri <eedri(a)redhat.com> wrote: > >> >> >> On Sun, Nov 20, 2016 at 1:42 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote: >> >>> >>> >>> On Sun, Nov 20, 2016 at 1:30 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote: >>> >>>> >>>> >>>> On Sun, Nov 20, 2016 at 1:18 PM, Eyal Edri <eedri(a)redhat.com> wrote: >>>> >>>>> the test fails to run VM because no hosts are in UP state(?) [1], not >>>>> sure it is related to the triggering patch[2] >>>>> >>>>> status: 400 >>>>> reason: Bad Request >>>>> detail: There are no hosts to use. Check that the cluster contains at >>>>> least one host in Up state. >>>>> >>>>> Thoughts? Shouldn't we fail the test earlier we hosts are not UP? >>>>> >>>> >>>> Yes. It's more likely that we are picking the wrong host or so, but who >>>> knows - where are the engine and VDSM logs? >>>> >>> >>> A simple grep on the engine.log[1] finds serveral unrelated issues I'm >>> not sure are reported, it's despairing to even begin... >>> That being said, I don't see the issue there. We may need better logging >>> on the API level, to see what is being sent. Is it consistent? >>> >> >> Just failed now the first time, I didn't see it before. >> >> >>> Y. >>> >>> >>> [1] http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_4. >>> 0/3015/artifact/exported-artifacts/basic_suite_4.0.sh-el7/ex >>> ported-artifacts/test_logs/basic-suite-4.0/post-004_basic_ >>> sanity.py/lago-basic-suite-4-0-engine/_var_log_ovirt-engine/engine.log >>> >>>> Y. >>>> >>>> >>>>> >>>>> >>>>> [1] http://jenkins.ovirt.org/job/test-repo_ovirt_experimenta >>>>> l_4.0/3015/testReport/junit/(root)/004_basic_sanity/vm_run/ >>>>> [2] http://jenkins.ovirt.org/job/ovirt-engine_4.0_build-arti >>>>> facts-el7-x86_64/1535/changes#detail >>>>> >>>>> >>>>> >>>>> On Sun, Nov 20, 2016 at 1:00 PM, <jenkins(a)jenkins.phx.ovirt.org> >>>>> wrote: >>>>> >>>>>> Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_4. >>>>>> 0/3015/, >>>>>> Build Number: 3015, >>>>>> Build Status: FAILURE >>>>>> _______________________________________________ >>>>>> Infra mailing list >>>>>> Infra(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/infra >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Eyal Edri >>>>> Associate Manager >>>>> RHV DevOps >>>>> EMEA ENG Virtualization R&D >>>>> Red Hat Israel >>>>> >>>>> phone: +972-9-7692018 >>>>> irc: eedri (on #tlv #rhev-dev #rhev-integ) >>>>> >>>> >>>> >>> >> >> >> -- >> Eyal Edri >> Associate Manager >> RHV DevOps >> EMEA ENG Virtualization R&D >> Red Hat Israel >> >> phone: +972-9-7692018 >> irc: eedri (on #tlv #rhev-dev #rhev-integ) >> > > -- Eyal Edri Associate Manager RHV DevOps EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

3 2

Re: [ovirt-devel] Where's MOM (on latest master)
by Michal Skrivanek 18 Nov '16

18 Nov '16

> On 18 Nov 2016, at 12:35, Martin Sivak <msivak(a)redhat.com> wrote: > >> I don't think it is related to version X or Y. It is a race, so might be >> related to other factors. > > It never (seriously: NEVER) happened with xml-rpc before 4.0.5. that is surprising but we also didn’t have lago before;-) > >> likely because json-rpc is initialized after xml-rpc….or indeed whatever >> else;-) > > But this is not about jsonrpc. The socket itself is shared according > to what Piotr said. it is > >> btw you likely still want to have a retry in mom once it >> starts responding due to delayed vdsm async recovery taking potentially >> minutes > > We handle this already. The only issue is the connection refused state. then why don’t you handle the connection state as well? isn’t that a simple fix? > > > Martin > > > On Fri, Nov 18, 2016 at 12:19 PM, Michal Skrivanek > <michal.skrivanek(a)redhat.com> wrote: >> >> On 18 Nov 2016, at 12:12, Oved Ourfali <oourfali(a)redhat.com> wrote: >> >> I don't think it is related to version X or Y. It is a race, so might be >> related to other factors. >> >> >> likely because json-rpc is initialized after xml-rpc….or indeed whatever >> else;-) >> >> either way it needs to be solved. Either by improving the systemd service >> file or mom retry (btw you likely still want to have a retry in mom once it >> starts responding due to delayed vdsm async recovery taking potentially >> minutes) >> >> >> On Nov 18, 2016 12:59 PM, "Martin Sivak" <msivak(a)redhat.com> wrote: >>> >>>> Are we / can we use systemd socket activation there? >>> >>> That actually requires systemd specific code iirc (to take over the >>> standing by socket). I am actually wondering why the xml-rpc in 4.0.4 >>> was fine and json-rpc in 4.0.6 is too slow. >>> >>> Martin >>> >>> On Fri, Nov 18, 2016 at 11:53 AM, Anton Marchukov <amarchuk(a)redhat.com> >>> wrote: >>>> Hello All. >>>> >>>> Are we / can we use systemd socket activation there? >>>> >>>> Anton. >>>> >>>> On Fri, Nov 18, 2016 at 11:21 AM, Martin Sivak <msivak(a)redhat.com> >>>> wrote: >>>>> >>>>> What about making vdsm ready to answer connections when it returns to >>>>> systemd instead? I hate workarounds and this always worked fine. >>>>> >>>>> Martin >>>>> >>>>> On Fri, Nov 18, 2016 at 11:13 AM, Oved Ourfali <oourfali(a)redhat.com> >>>>> wrote: >>>>>> Seems like a race regardless of the protocol. >>>>>> Should you add a retry? >>>>>> >>>>>> >>>>>> On Nov 18, 2016 11:52 AM, "Martin Sivak" <msivak(a)redhat.com> wrote: >>>>>>> >>>>>>> Yes, because VDSM is supposed to be up (there is systemd >>>>>>> dependency). >>>>>>> This always worked fine with xml-rpc. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> On Fri, Nov 18, 2016 at 10:14 AM, Nir Soffer <nsoffer(a)redhat.com> >>>>>>> wrote: >>>>>>>> On Fri, Nov 18, 2016 at 10:45 AM, Martin Sivak <msivak(a)redhat.com> >>>>>>>> wrote: >>>>>>>>> This happens because MOM can't connect to VDSM and so it quits. >>>>>>>> >>>>>>>> So mom try once to connect and if the connection fails it quits? >>>>>>>> >>>>>>>>> We >>>>>>>>> discussed it on the mailinglist >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> https://lists.fedoraproject.org/archives/list/vdsm-devel@lists.fedorahosted… >>>>>>>>> http://lists.ovirt.org/pipermail/devel/2016-November/014101.html >>>>>>>>> >>>>>>>>> This issue never happened with XML-RPC. >>>>>>>>> >>>>>>>>> Shira reported it as >>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1393012 >>>>>>>>> >>>>>>>>> Martin >>>>>>>>> >>>>>>>>> On Thu, Nov 17, 2016 at 7:42 PM, Yaniv Kaul <ykaul(a)redhat.com> >>>>>>>>> wrote: >>>>>>>>>> I've recently seen, including now on Master, the following >>>>>>>>>> warnings: >>>>>>>>>> Nov 17 13:33:25 lago-basic-suite-master-host0 systemd[1]: >>>>>>>>>> Started >>>>>>>>>> MOM >>>>>>>>>> instance configured for VDSM purposes. >>>>>>>>>> Nov 17 13:33:25 lago-basic-suite-master-host0 systemd[1]: >>>>>>>>>> Starting >>>>>>>>>> MOM >>>>>>>>>> instance configured for VDSM purposes... >>>>>>>>>> Nov 17 13:33:35 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, Policy could not be set. >>>>>>>>>> Nov 17 13:33:39 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> Nov 17 13:33:39 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, KSM stats will be missing. >>>>>>>>>> Nov 17 13:33:55 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> Nov 17 13:33:55 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, KSM stats will be missing. >>>>>>>>>> Nov 17 13:34:10 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> Nov 17 13:34:10 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, KSM stats will be missing. >>>>>>>>>> Nov 17 13:34:26 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> Nov 17 13:34:26 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, KSM stats will be missing. >>>>>>>>>> Nov 17 13:34:42 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> Nov 17 13:34:42 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, KSM stats will be missing. >>>>>>>>>> Nov 17 13:34:57 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> Nov 17 13:34:57 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available, KSM stats will be missing. >>>>>>>>>> Nov 17 13:35:12 lago-basic-suite-master-host0 vdsm[2012]: vdsm >>>>>>>>>> MOM >>>>>>>>>> WARN MOM >>>>>>>>>> not available. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Any ideas what this is and why? >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Devel mailing list >>>>>>>>>> Devel(a)ovirt.org >>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>>>>> _______________________________________________ >>>>>>>>> Devel mailing list >>>>>>>>> Devel(a)ovirt.org >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>>> _______________________________________________ >>>>>>> Devel mailing list >>>>>>> Devel(a)ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>>> >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Devel mailing list >>>>> Devel(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>> >>>> >>>> >>>> >>>> -- >>>> Anton Marchukov >>>> Senior Software Engineer - RHEV CI - Red Hat >>>> >> >> _______________________________________________ >> Devel mailing list >> Devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> >>

2 1

Where's MOM (on latest master)
by Yaniv Kaul 18 Nov '16

18 Nov '16

I've recently seen, including now on Master, the following warnings: Nov 17 13:33:25 lago-basic-suite-master-host0 systemd[1]: Started MOM instance configured for VDSM purposes. Nov 17 13:33:25 lago-basic-suite-master-host0 systemd[1]: Starting MOM instance configured for VDSM purposes... Nov 17 13:33:35 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, Policy could not be set. Nov 17 13:33:39 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Nov 17 13:33:39 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, KSM stats will be missing. Nov 17 13:33:55 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Nov 17 13:33:55 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, KSM stats will be missing. Nov 17 13:34:10 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Nov 17 13:34:10 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, KSM stats will be missing. Nov 17 13:34:26 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Nov 17 13:34:26 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, KSM stats will be missing. Nov 17 13:34:42 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Nov 17 13:34:42 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, KSM stats will be missing. Nov 17 13:34:57 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Nov 17 13:34:57 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available, KSM stats will be missing. Nov 17 13:35:12 lago-basic-suite-master-host0 vdsm[2012]: vdsm MOM WARN MOM not available. Any ideas what this is and why?

7 15

Introduce new package decencies in vdsm
by Yaniv Bronheim 17 Nov '16

17 Nov '16

Hi After merging https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:c… we need now for any new requirement to add a line in: check-patch.packages.el7 check-patch.packages.fc24 check-merged.packages.el7 check-merged.packages.fc24 vdsm.spec.in Dockerfile.centos Dockerfile.fedora seems like we can add it once to the spec with section for fedora and centos and the rest of the places will use yum-builddep. sounds more reasonable to me and probably the right way to work with rpms dependencies. no? *Yaniv Bronhaim.*

4 4

oVirt Neutron External Provider
by Than Maung 17 Nov '16

17 Nov '16

All, Is there a guide for getting oVirt 4.0.4 going with networks created in Neutron? We are having problems with VMs not getting DHCP at all but they are showing up in the OpenStack Dashboard interface under Ports with the correct MAC IDs and the IP that the DHCP agent had assigned them. I'm using OpenStack Newton version and the controller is working all properly. We are trying to follow these two guides in trying to get virtual networks to work but experiencing problems. http://docs.openstack.org/newton/install-guide-rdo/neutron.html http://captainkvm.com/2016/09/integrating-rhv-openstack-neutron/ Sincerely, -- Than H. Maung, CISSP tmaung(a)techintsolutions.com (571) 295-8462

3 2

Vdsm build failure
by Piotr Kliczewski 17 Nov '16

17 Nov '16

All, I see a build failure [1] due to: 13:34:32 FAIL: test_from_invalid_to_valid_domain('selftest', <type 'exceptions.OSError'>) (storage_monitor_test.TestMonitorThreadMonitoring) 13:34:32 ---------------------------------------------------------------------- 13:34:32 Traceback (most recent call last): 13:34:32 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/testlib.py", line 133, in wrapper 13:34:32 return f(self, *args) 13:34:32 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/storage_monitor_test.py", line 470, in test_from_invalid_to_valid_domain 13:34:32 self.assertTrue(status.valid) 13:34:32 AssertionError: False is not true 13:34:32 -------------------- >> begin captured logging << -------------------- 13:34:32 2016-11-14 13:33:04,968 DEBUG (monitor/uuid) [storage.Monitor] Domain monitor for uuid started (monitor:304) 13:34:32 2016-11-14 13:33:04,968 DEBUG (monitor/uuid) [storage.Monitor] Producing domain uuid (monitor:366) 13:34:32 2016-11-14 13:33:04,969 INFO (monitor/uuid) [test] Start checking '/path/to/metadata' (storage_monitor_test:73) 13:34:32 2016-11-14 13:33:04,969 DEBUG (monitor/uuid) [test] Checking if iso domain (storage_monitor_test:156) 13:34:32 2016-11-14 13:33:04,969 ERROR (monitor/uuid) [storage.Monitor] Error checking domain uuid (monitor:426) 13:34:32 Traceback (most recent call last): 13:34:32 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/vdsm/storage/monitor.py", line 407, in _checkDomainStatus 13:34:32 self.domain.selftest() 13:34:32 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/testlib.py", line 616, in wrapper 13:34:32 raise exception 13:34:32 OSError 13:34:32 2016-11-14 13:33:04,969 INFO (monitor/uuid) [storage.Monitor] Domain uuid became INVALID (monitor:456) 13:34:32 2016-11-14 13:33:04,969 DEBUG (monitor/uuid) [test] Emitting event (args=('uuid', False), kwrags={}) (storage_monitor_test:57) 13:34:32 2016-11-14 13:33:05,170 ERROR (monitor/uuid) [storage.Monitor] Error checking domain uuid (monitor:426) 13:34:32 Traceback (most recent call last): 13:34:32 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/vdsm/storage/monitor.py", line 407, in _checkDomainStatus 13:34:32 self.domain.selftest() 13:34:32 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/testlib.py", line 616, in wrapper 13:34:32 raise exception 13:34:32 OSError 13:34:32 2016-11-14 13:33:05,371 ERROR (monitor/uuid) [storage.Monitor] Error checking domain uuid (monitor:426) 13:34:32 Traceback (most recent call last): 13:34:32 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/vdsm/storage/monitor.py", line 407, in _checkDomainStatus 13:34:32 self.domain.selftest() 13:34:32 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/testlib.py", line 616, in wrapper 13:34:32 raise exception 13:34:32 OSError 13:34:32 2016-11-14 13:33:05,461 DEBUG (monitor/uuid) [storage.Monitor] Domain monitor for uuid canceled (monitor:309) 13:34:32 2016-11-14 13:33:05,461 DEBUG (monitor/uuid) [storage.Monitor] Domain monitor for uuid stopped (shutdown=False) (monitor:312) 13:34:32 2016-11-14 13:33:05,461 INFO (monitor/uuid) [test] Stop checking '/path/to/metadata' (storage_monitor_test:79) 13:34:32 2016-11-14 13:33:05,461 DEBUG (monitor/uuid) [test] Releasing host id (hostId=host_id, unused=True) (storage_monitor_test:143) 13:34:32 2016-11-14 13:33:05,461 ERROR (monitor/uuid) [storage.Monitor] Error releasing host id host_id for domain uuid (monitor:568) 13:34:32 Traceback (most recent call last): 13:34:32 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/vdsm/storage/monitor.py", line 565, in _releaseHostId 13:34:32 self.domain.releaseHostId(self.hostId, unused=True) 13:34:32 File "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/storage_monitor_test.py", line 146, in releaseHostId 13:34:32 assert self.acquired, "Attempt to release unacquired host id" 13:34:32 AssertionError: Attempt to release unacquired host id Can someone please take a look? Thanks, Piotr [1] http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-x86_64/4123/conso…

1 1

oVirt 4.0.6 RC1 build planned
by Rafael Martins 16 Nov '16

16 Nov '16

Fyi oVirt developers, An oVirt build is planned for this Wednesday 10:00 AM TLV time (9:00 AM CET). Taking into consideration the time it takes for Jenkins to run a full CI everything need to be backported by Tuesday 11PM. Please make sure to mark as verified and CR +2 so it will be ready for merging Wednesday morning. A list of pending blockers is available here: https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A4.0.… Rafael

3 2

[VDSM] Failing make check
by Adam Litke 16 Nov '16

16 Nov '16

Hi Piotr, I am now seeing consistent Jenkins failures during make check (when producing the schema html doc) and I suspect this[1] change. Can you take a look please? [1] https://gerrit.ovirt.org/#/c/56387/ -- Adam Litke

2 1