September 2012 - Devel - Ovirt List Archives

[Engine-devel] is gerrit.ovirt.org down? <eom>

by Shireesh Anjal

12 years, 3 months

8
10
0 / 0

[Engine-devel] Fixed -Xmx could kill your JVM

by Juan Hernandez

Hello, I recently discovered that I made a mistake in the engine service script. The problem is that were running the JVM with the "-Xms option twice, like this: java -Xms1g -Xms1g ... That doesn't correctly limit the max amount of heap space. It has been fixed in a recent commit [1], so with the updated code the engine will run by default like this: java -Xms1g -Xmx1g ... With this change you could start to see OutOfMemory errors if your engine was using a lot of memory, if you are running stress tests, for example. In that case remember that you can adjust this changing the ENGINE_HEAP_MIN and ENGINE_HEAP_MAX parameters in /etc/sysconfig/ovirt-engine. For example, to use 2g instead of the default of 1g: ENGINE_HEAP_MIN=2g ENGINE_HEAP_MAX=2g The restart the engine. Let me know if you have issues. Regards, Juan Hernandez [1] http://gerrit.ovirt.org/7952 -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.

12 years, 3 months

4
4
0 / 0

[Engine-devel] network subnet

by Livnat Peer

Hi All, Today when a user wants to define a network subnet mask, he does it when he attaches the network to a host NIC. I was wondering if there is a reason not to define the network subnet on the logical network entity (Data center level). Thanks, Livnat

12 years, 3 months

4
8
0 / 0

[Engine-devel] what does engine with cpuIdle?

by Laszlo Hornyak

hi, I am trying to change a behavior in vdsm. When you pass 100% load on a VM, it will stop reporting further load and will keep telling 100% until the load drops under 100% again in it's cpuIdle information. This is totally correct if you have only single-cpu VM's, but it is false when you have multiple vcpu's, I think the cpuIdle information should not be on a 0-100 scale, but on a 0-100*vcpus scale. So I submitted this patch to vdsm: http://gerrit.ovirt.org/#/c/7892/2 and Dan pointed out that some functionality may depend on the value in the 0-100 interval. For me it seems it is ignored and the load is calculated only from sysCpu + userCpu. Does anyone build on the cpuIdle value? Thanks, Laszlo

12 years, 3 months

4
8
0 / 0

[Engine-devel] i18n status / availability of pot files for translators

by David Jaša

Hi, I was wondering about $SUBJ. When will translators be able to lay their hands on the initial .pot files, sometimes around 3.2 freeze? The only mention of translation I've seen is in release notes of 3.1 promising translations to be included in 3.2, so it would be quite nice to give translators some time to work on them... David -- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24

12 years, 3 months

3
3
0 / 0

[Engine-devel] Fwd: [oss-security] CVE Request (minor) -- JVM: heap memory disclosure (possibly various JDKs)

by Michael Pasternak

-------- Original Message -------- Subject: [oss-security] CVE Request (minor) -- JVM: heap memory disclosure (possibly various JDKs) Hello Kurt, Steve, vendors, an information disclosure flaw was found in the way certain Java Virtual Machines (JVM) used to initialize integer arrays (they have had nonzero elements right after the allocation in certain circumstances). An attacker could use this flaw to obtain potentially sensitive information. References (including the reproducer, workaround and further details): [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7196857 [2] https://bugzilla.redhat.com/show_bug.cgi?id=856124 Could you allocate a CVE id for this? Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team P.S.: Issue brought to us by Florian Weimer, Red Hat Product Security Team (for case someone is tracking the initial reporter) P.S#2: Oracle Security Team Cc-ed on this request too (to clarify if CVE id has been assigned to this already or not). -- Michael Pasternak RedHat, ENG-Virtualization R&D

12 years, 3 months

1
0
0 / 0

Re: [Engine-devel] UI Plugins configuration

by Vojtech Szocs

------=_Part_12944838_269192103.1345724057851 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Chris, thanks for taking the time to make this patch, these are some excellent ideas! (CC'ing engine-devel so that we can discuss this with other guys as well) First of all, I really like the way you designed plugin source page URLs (going through PluginSourcePageServlet ), e.g. "/webadmin/webadmin/plugin/<pluginName>/<pluginSourcePage>.html", plus the concept of "path" JSON attribute. WebadminDynamicHostingServlet loads and caches all plugin definitions ( *.json files), and directly embeds them into WebAdmin host page as pluginDefinitions JavaScript object. I'm assuming that pluginDefinitions object will now look like this: var pluginDefinitions = { "test": { "name": "test", "version": "1.0", "url": "/webadmin/webadmin/plugin/test/foo.html", "path": "/tmp", "config": {"a":1, "b":2, "c":3} } } Originally, the pluginDefinitions object looked like this: var pluginDefinitions = { "test": "/webadmin/webadmin/plugin/test/foo.html" // Simple pluginName -> pluginSourcePageUrl mappings } This is because PluginManager (WebAdmin) only needs pluginName ("name") and pluginSourcePageUrl ("url") during startup, when creating plugin iframe. But this can be changed :) Plugin "version" makes sense, plus the plugin configuration object ("config") can be useful directly on the client. Let me explain: Originally, plugin configuration was supposed to be passed to actual plugin code (through immediately-invoked-function-expression, or IIFE), just like this: (function (pluginApi, pluginConfig) { // JavaScript IIFE // ... actual plugin code ... })( parent.pluginApi, /* reference to global pluginApi object */ {"a":1, "b":2, "c":3} /* embedded plugin configuration as JavaScript object */ ); The whole purpose of PluginSourcePageServlet was to "wrap" actual plugin code into HTML, so that users don't need to write HTML pages for their plugins manually. PluginSourcePageServlet would handle any plugin dependencies (placed into HTML head), with actual plugin code being wrapped into IIFE, as shown above. Plugin configuration was meant to be stored in a separate file, e.g. <pluginName>-config.json , so that users could change the default plugin configuration to suit their needs. Inspired by your patch, rather than reading/embedding plugin configuration when serving plugin HTML page ( PluginSourcePageServlet ), it's even better to have the plugin configuration embedded directly into WebAdmin host page, along with introducing new pluginApi function to retrieve the plugin configuration object. Based on this, I suggest following modifications to the original concept: - modify original pluginDefinitions structure, from pluginName -> pluginSourcePageUrl , to pluginName -> pluginDefObject - pluginDefObject is basically a subset of physical plugin definition ( test.json , see below), suitable for use on the client - add following attributes to pluginDefObject : version , url , config * note #1: name is not needed, since it's already the key of pluginName -> pluginDefObject mapping * note #2: path is not needed on the client (more on this below) - introduce pluginApi.config(pluginName) function for plugins to retrieve their configuration object, and remove pluginConfig parameter from main IIFE (as shown above) [a] Physical plugin definition file (JSON) might be located at oVirt "DataDir", e.g. /usr/share/ovirt-engine/ui-plugins/test.json , for example: { "name": "test", "version": "1.0", "url": "/webadmin/webadmin/plugin/test/start.html", "path": "/tmp", "config": "test-config.json" } [b] Plugin configuration file (JSON) might be located at oVirt "ConfigDir", e.g. /etc/ovirt-engine/ui-plugins/test-config.json , for example: { "a":1, "b":2, "c":3 } [c] Finally, plugin static resources (plugin source page, actual plugin code, plugin dependencies, CSS/images, etc.) would be located at /tmp (as shown in [a]), for example: /tmp/start.html -> plugin source page, used to load actual plugin code /tmp/test.js -> actual plugin code /tmp/deps/jquery-min.js -> simulate 3rd party plugin dependency For example: "/webadmin/webadmin/plugin/test/start.html" will be mapped to /tmp/start.html "/webadmin/webadmin/plugin/test/deps/jquery-min.js" will be mapped to /tmp/deps/jquery-min.js This approach has some pros and cons: (+) plugin static resources can be served through PluginSourcePageServlet (pretty much like oVirt documentation resources, served through oVirt Engine root war's FileServlet ) (+) plugin author has complete control over plugin source page (-) plugin author actually needs to write plugin source page Overall, I think this approach is better than the previous one (where PluginSourcePageServlet took care of rendering plugin source page, but sacrificed some flexibility). By the way, here's what would happen behind the scenes: 1. user requests WebAdmin host page, WebadminDynamicHostingServlet loads and caches all plugin definitions [a] + plugin configurations [b] and constructs/embeds appropriate pluginDefinitions JavaScript object 2. during WebAdmin startup, PluginManager registers the plugin (name/version/url/config), and creates/attaches the iframe to fetch plugin source page ansynchronously 3. PluginSourcePageServlet handles plugin source page request, resolves the correct path [c] and just streams the file content back to client > 1. The plugin configuration files should probably have an "enabled" field and an "apiVersion" field that should be examined to determine whether or not to use the plugin. Sounds good, we can implement these later on :) > 2. I suspect the way I've modified PluginSourcePage makes it vulnerable to directory climbing attacks. Yes, but we can defend against these, restricting access only to plugin's "path" and its sub-directories. > 3. Is /usr/share/ovirt-engine the right place for the plugin config files? I suppose you mean plugin definition files [a], cannot tell for sure, but we can change this anytime :) Chris, please let me know what you think, and again - many thanks for sending the patch! Regards, Vojtech ----- Original Message ----- From: "Chris Frantz" <Chris.Frantz(a)hp.com> To: vszocs(a)redhat.com Sent: Wednesday, August 22, 2012 7:56:45 PM Subject: UI Plugins configuration Vojtech, I decided to work on making the plugin patch a bit more configurable, following some of the ideas expressed by Itamar and others in the meeting yesterday. The attached patch is a simple first-attempt. Plugin configurations are stored in /usr/share/ovirt-engine/ui-plugins/*.json. Example: { "name": "test", "version": "1.0", "url": "/webadmin/webadmin/plugin/test/foo.html", "path": "/tmp", "config": {"a":1, "b":2, "c": 3} } The engine reads all of the *.json files in that directory to build the list of known plugins and gives that list to the webadmin. When webadmin loads a plugin, it requests the URL given in the plugin config file. The "plugin" URL is mapped to PluginSourcePage, which will translate the first part of the path ("test") into whatever path is stored in pluginConfig ("/tmp") in this case, and then serve the static file (e.g. "/tmp/foo.html"). I didn't use the renderPluginSourcePage() method in favor of just serving a static file, but I have no strong opinion on the matter. However, a plugin may want to store static resources at "path" and have the engine serve those resources. By just serving files through PluginSourcePage, we don't need any other servlets to provide those resources. There is still a bit of work to do: 1. The plugin configuration files should probably have an "enabled" field and an "apiVersion" field that should be examined to determine whether or not to use the plugin. 2. I suspect the way I've modified PluginSourcePage makes it vulnerable to directory climbing attacks. 3. Is /usr/share/ovirt-engine the right place for the plugin config files? Let me know what you think, --Chris ------=_Part_12944838_269192103.1345724057851 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: times new roman,new york,times,serif; font-size: = 12pt; color: #000000'>Hi Chris, thanks for taking the time to make t= his patch, these are some excellent ideas! (CC'ing engine-devel so that we = can discuss this with other guys as well) First of all, I really lik= e the way you designed plugin source page URLs (going through PluginSou= rcePageServlet), e.g. "/webadmin/webadmin/plugin/<pluginName>/&l= t;pluginSourcePage>.html", plus the concept of "path" JSON attribute.<br= > WebadminDynamicHostingServlet</spa= n> loads and caches all plugin definitions (*.json files), and directly embeds them into WebAdmin host page= as pluginDefinitions JavaScript= object. I'm assuming that pluginDefini= tions object will now look like this: var pluginDefinition= s =3D {   "test": {     "name"= : "test",     "version": "1.0",  &n= bsp;  "url": "/webadmin/webadmin/plugin/test/foo.html", &nbs= p;   "path": "/tmp",     "config": {"a":= 1, "b":2, "c":3}   } } Original= ly, the pluginDefinitions object= looked like this: var pluginDefinitions =3D {  &nbsp= ;"test": "/webadmin/webadmin/plugin/test/foo.html" // Simple pluginName -&g= t; pluginSourcePageUrl mappings } This is because P= luginManager (WebAdmin) only needs plug= inName ("name") and pluginSource= PageUrl ("url") during startup, when creating plugin iframe. But thi= s can be changed :) Plugin "version" makes sense, plus the plugin co= nfiguration object ("config") can be useful directly on the client. Let me = explain: Originally, plugin configuration was supposed to be passed = to actual plugin code (through immediately-invoked-function-expression, or = IIFE), just like this: (function (pluginApi, pluginConfig) { // Java= Script IIFE   // ... actual plugin code ... <spa= n style=3D"font-family: courier new,courier,monaco,monospace,sans-serif;">}= )(   parent.pluginApi, /* reference to global pluginApi= object */   {"a":1, "b":2, "c":3} /* embedded plugin c= onfiguration as JavaScript object */ ); The whole p= urpose of PluginSourcePageServlet</span= > was to "wrap" actual plugin code into HTML, so that users don't need to w= rite HTML pages for their plugins manually. PluginSourcePageServlet would handle any plugin dependencies (p= laced into HTML head), with actual plugin code being wrapped into IIFE, as = shown above. Plugin configuration was meant to be stored in a separate file= , e.g. <pluginName>-config.json</= span>, so that users could change the default plugin configuration to suit = their needs. Inspired by your patch, rather than reading/embedding p= lugin configuration when serving plugin HTML page (PluginSourcePageServlet), it's even better to have the p= lugin configuration embedded directly into WebAdmin host page, along with i= ntroducing new pluginApi functio= n to retrieve the plugin configuration object. Based on this, I sugg= est following modifications to the original concept: - modify origin= al pluginDefinitions structure, = from pluginName -> pluginSourcePageU= rl, to pluginName -> pluginDe= fObject - pluginDefObject</sp= an> is basically a subset of physical plugin definition (test.json, see below), suitable for use on the cli= ent - add following attributes to pl= uginDefObject: version, <= span style=3D"font-style: italic;">url, config   * note #1: name is not needed, since it's already the key of pluginName -> pluginDefObject mapping<= br>  * note #2: path i= s not needed on the client (more on this below) - introduce pluginApi.config(pluginName) function for p= lugins to retrieve their configuration object, and remove pluginConfig parameter from main IIFE (as shown a= bove) [a] Physical plugin definition file (JSON) might be located at= oVirt "DataDir", e.g. /usr/share/ovirt= -engine/ui-plugins/test.json, for example: { &nbsp= ; "name": "test",   "version": "1.0", <span= style=3D"font-family: courier new,courier,monaco,monospace,sans-serif;">&n= bsp; "url": "/webadmin/webadmin/plugin/test/start.html", &nb= sp; "path": "/tmp",   "config": "test-config.json"= } [b] Plugin configuration file (JSON) might be lo= cated at oVirt "ConfigDir", e.g. /etc/o= virt-engine/ui-plugins/test-config.json, for example: {</sp= an>   "a":1, "b":2, "c":3 } [c] Finall= y, plugin static resources (plugin source page, actual plugin code, plugin = dependencies, CSS/images, etc.) would be located at /tmp (as shown in [a]), for example: /tmp/start.= html -> plugin source page, used to load actual plugin code <span= style=3D"font-family: courier new,courier,monaco,monospace,sans-serif;">/t= mp/test.js -> actual plugin code /tmp/deps/jquery-min.js ->= simulate 3rd party plugin dependency For example: "/webad= min/webadmin/plugin/test/start.html" will be mapped to /tmp/start.html "/webadmin/webadmin/plugin/test/d= eps/jquery-min.js" will be mapped to /t= mp/deps/jquery-min.js This approach has some pros and cons:<b= r>(+) plugin static resources can be served through PluginSourcePageServlet (pretty much like oVirt documen= tation resources, served through oVirt Engine root war's FileServlet) (+) plugin author has complete con= trol over plugin source page (-) plugin author actually needs to write p= lugin source page Overall, I think this approach is better than the = previous one (where PluginSourcePageSer= vlet took care of rendering plugin source page, but sacrificed some = flexibility). By the way, here's what would happen behind the scenes= : <ol><li>user requests WebAdmin host page, WebadminDynamicHostingServlet loads and caches all plugin de= finitions [a] + plugin configurations [b] and constructs/embeds appropriate= pluginDefinitions JavaScript ob= ject </li><li>during WebAdmin startup, PluginManager registers the plugin (name/version/url/config),= and creates/attaches the iframe to fetch plugin source page ansynchronousl= y </li><li>PluginSourcePageServl= et handles plugin source page request, resolves the correct path [c]= and just streams the file content back to client </li></ol>> 1. =  The plugin configuration files should probably have an "enabled"=20 field and an "apiVersion" field that should be examined to determine=20 whether or not to use the plugin. Sounds good, we can implement thes= e later on :) > 2.  I suspect the way I've modified PluginSo= urcePage makes it vulnerable to directory climbing attacks. Yes, but= we can defend against these, restricting access only to plugin's "path" an= d its sub-directories. > 3.  Is /usr/share/ovirt-engine the = right place for the plugin config files? I suppose you mean plugin d= efinition files [a], cannot tell for sure, but we can change this anytime := ) Chris, please let me know what you think, and again - many tha= nks for sending the patch! Regards, Vojtech <hr id= =3D"zwchr"> From: "Chris Frantz" <Chris.Frantz(a)hp.com> To: vszo= cs(a)redhat.com Sent: Wednesday, August 22, 2012 7:56:45 PM Subject: UI= Plugins configuration Vojtech, I decided to work on making t= he plugin patch a bit more configurable, following some of the ideas expres= sed by Itamar and others in the meeting yesterday.  The attached patch= is a simple first-attempt. Plugin configurations are stored in /usr= /share/ovirt-engine/ui-plugins/*.json. Example: {   =       "name": "test",    &n= bsp;    "version": "1.0",     &n= bsp;   "url": "/webadmin/webadmin/plugin/test/foo.html", =         "path": "/tmp",  &n= bsp;      "config": {"a":1, "b":2, "c": 3}<br= >} The engine reads all of the *.json files in that directory to bui= ld the list of known plugins and gives that list to the webadmin. Wh= en webadmin loads a plugin, it requests the URL given in the plugin config = file.  The "plugin" URL is mapped to PluginSourcePage, which will tran= slate the first part of the path ("test") into whatever path is stored in p= luginConfig ("/tmp") in this case, and then serve the static file (e.g. "/t= mp/foo.html"). I didn't use the renderPluginSourcePage() method in f= avor of just serving a static file, but I have no strong opinion on the mat= ter.  However, a plugin may want to store static resources at "path" a= nd have the engine serve those resources.  By just serving files throu= gh PluginSourcePage, we don't need any other servlets to provide those reso= urces. There is still a bit of work to do: 1.  The plugi= n configuration files should probably have an "enabled" field and an "apiVe= rsion" field that should be examined to determine whether or not to use the= plugin. 2.  I suspect the way I've modified PluginSourcePage m= akes it vulnerable to directory climbing attacks. 3.  Is /usr/s= hare/ovirt-engine the right place for the plugin config files? Let m= e know what you think, --Chris </div></body></html> ------=_Part_12944838_269192103.1345724057851--

12 years, 3 months

5
13
0 / 0

[Engine-devel] Java EE 7 roadmap changes

by Doron Fediuck

https://blogs.oracle.com/theaquarium/entry/java_ee_7_roadmap

12 years, 3 months

1
0
0 / 0

[Engine-devel] commit breaks ovirt-engine due to compilation error

by Eyal Edri

this commit break ovirt-engine on jenkins.ovirt.org: http://jenkins.ovirt.org/job/ovirt_engine_animal_sniffer_check/425/org.ov... core: add vdsName to vdsBroker log info (#853883) (details) Commit 35c2e7ceb5109c9349e3699c3f53414cbe0b4c4e by ybronhei core: add vdsName to vdsBroker log info (#853883) https://bugzilla.redhat.com/show_bug.cgi?id=853883 Logger gets VdsCommandBase.toString() method's output, this patch adds call to getAdditionalInformation from toString to add to log string VdsName. Change-Id: Ieb0589bb5f5e157c04f85e46f6769d66ef98b2d1 Signed-off-by: Yaniv Bronhaim <ybronhei(a)redhat.com> please check, Eyal. [INFO] [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ vdsbroker --- [INFO] ------------------------------------------------------------- [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] /home/jenkins/workspace/ovirt_engine_animal_sniffer_check/backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/RemoveVdsVDSCommand.java:[5,7] error: RemoveVdsVDSCommand is not abstract and does not override abstract method getAdditionalInformation() in VDSCommandBase [ERROR] /home/jenkins/workspace/ovirt_engine_animal_sniffer_check/backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/UpdateVmDynamicDataVDSCommand.java:[5,7] error: UpdateVmDynamicDataVDSCommand is not abstract and does not override abstract method getAdditionalInformation() in VDSCommandBase [ERROR] /home/jenkins/workspace/ovirt_engine_animal_sniffer_check/backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/FailedToRunVmVDSCommand.java:[5,7] error: FailedToRunVmVDSCommand is not abstract and does not override abstract method getAdditionalInformation() in VDSCommandBase [ERROR] /home/jenkins/workspace/ovirt_engine_animal_sniffer_check/backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/ActivateVdsVDSCommand.java:[5,7] error: ActivateVdsVDSCommand is not abstract and does not override abstract method getAdditionalInformation() in VDSCommandBase [ERROR] /home/jenkins/workspace/ovirt_engine_animal_sniffer_check/backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/CreateVmVDSCommand.java:[28,7] error: CreateVmVDSCommand is not abstract and does not override abstract method getAdditionalInformation() in VDSCommandBase [ERROR] /home/jenkins/workspace/ovirt_engine_animal_sniffer_check/backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/UpdateVdsVMsClearedVDSCommand.java:[5,7] error: UpdateVdsVMsClearedVDSCommand is not abstract and does not override abstract method getAdditionalInformation() in VDSCommandBase [ERROR] /home/jenkins/workspace/ovirt_engine_animal_sniffer_check/backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/AddVdsVDSCommand.java:[12,7] error: AddVdsVDSCommand is not abstract and does not override abstract method getAdditionalInformation() in VDSCommandBase [ERROR] /home/jenkins/workspace/ovirt_engine_animal_sniffer_check/backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/SetVdsStatusVDSCommand.java:[13,7] error: SetVdsStatusVDSCommand is not abstract and does not override abstract method getAdditionalInformation() in VDSCommandBase [ERROR] /home/jenkins/workspace/ovirt_engine_animal_sniffer_check/backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/ResumeVDSCommand.java:[10,7] error: ResumeVDSCommand is not abstract and does not override abstract method getAdditionalInformation() in VDSCommandBase [ERROR] /home/jenkins/workspace/ovirt_engine_animal_sniffer_check/backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/DestroyVmVDSCommand.java:[18,7] error: DestroyVmVDSCommand is not abstract and does not override abstract method getAdditionalInformation() in VDSCommandBase [ERROR] /home/jenkins/workspace/ovirt_engine_animal_sniffer_check/backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/MigrateVDSCommand.java:[21,7] error: MigrateVDSCommand is not abstract and does not override abstract method getAdditionalInformation() in VDSCommandBase [ERROR] /home/jenkins/workspace/ovirt_engine_animal_sniffer_check/backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/UpdateVdsDynamicDataVDSCommand.java:[5,7] error: UpdateVdsDynamicDataVDSCommand is not abstract and does not override abstract method getAdditionalInformation() in VDSCommandBase [INFO] 12 errors [INFO] ------------------------------------------------------------- mojoFailed org.apache.maven.plugins:maven-compiler-plugin:2.3.2(default-compile) projectFailed org.ovirt.engine.core:vdsbroker:3.1.0

12 years, 3 months

2
1
0 / 0

[Engine-devel] No disk space in gerrit server?

by Selvasundaram

The following error seems to be no disk space in gerrit server. Counting objects: 62, done. Delta compression using up to 4 threads. Compressing objects: 100% (23/23), done. Writing objects: 100% (38/38), 9.28 KiB, done. Total 38 (delta 9), reused 0 (delta 0) error: unpack failed: error No space left on device fatal: Unpack error, check server log To gerrit.ovirt.org:ovirt-engine ! [remote rejected] HEAD -> refs/for/master (n/a (unpacker error)) error: failed to push some refs to 'gerrit.ovirt.org:ovirt-engine' -- Regards Selvasundaram

12 years, 3 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Devel September 2012