- Devel - oVirt List Archives

[Engine-devel] Fwd: [oss-security] CVE Request (minor) -- JVM: heap memory disclosure (possibly various JDKs)
by Michael Pasternak 11 Sep '12

11 Sep '12

-------- 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

1 0

Re: [Engine-devel] UI Plugins configuration
by Vojtech Szocs 11 Sep '12

11 Sep '12

------=_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--

5 13

[Engine-devel] Java EE 7 roadmap changes
by Doron Fediuck 10 Sep '12

10 Sep '12

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

1 0

[Engine-devel] commit breaks ovirt-engine due to compilation error
by Eyal Edri 09 Sep '12

09 Sep '12

this commit break ovirt-engine on jenkins.ovirt.org: http://jenkins.ovirt.org/job/ovirt_engine_animal_sniffer_check/425/org.ovir… 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

2 1

[Engine-devel] No disk space in gerrit server?
by Selvasundaram 07 Sep '12

07 Sep '12

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

2 1

[Engine-devel] GUI patches: verify on 2 browsers
by Einav Cohen 06 Sep '12

06 Sep '12

oVirt-engine developers/reviewers: oVirt-engine patches that involve GUI changes (i.e. web admin and/or user portal) *must* be verified on at least two different browsers out of the following: firefox/chrome/ie ---- Thanks, Einav

3 5

[Engine-devel] updating disk /api/disks/xxx
by Michael Pasternak 06 Sep '12

06 Sep '12

i see in BackendDiskResource.update(), what is the status if this item? @Override public Disk update(Disk disk) { //TODO: implmenet when Backend is ready. Implementation stub: // return performUpdate(this, new QueryIdResolver(VdcQueryType.GetDiskByDiskId, GetDiskByDiskIdParameters.class), ?, ?); throw new NotImplementedException("Pending Backend support"); } -- Michael Pasternak RedHat, ENG-Virtualization R&D

3 4

[Engine-devel] waiting for review
by Laszlo Hornyak 05 Sep '12

05 Sep '12

hi, I have some patches waiting for review. Some of them are not quite new. But anyway, if you have some time, your reviews are welcome. http://gerrit.ovirt.org/#/dashboard/1000027 Thx, Laszlo

1 0

Re: [Engine-devel] Change in ovirt-engine[master]: webadmin: DirectLUN - confirmation dialog for SD LUN (#84806...
by thomas＠parker.iz34.com 05 Sep '12

05 Sep '12

----boundary_0_521195f1-d75b-475a-8c1a-053655bbd25b Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Daniel Erez has submitted this change and it was merged. Change subject: webadmin: DirectLUN - confirmation dialog for SD LUN (#848067) ..................................................................... webadmin: DirectLUN - confirmation dialog for SD LUN (#848067) https://bugzilla.redhat.com/848067 DirectLUN disk - when choosing a LUN that is already part of a storage domain, display a warning confirmation dialog with a latch. Change-Id: I1f303381142d869d162ad6c181dc715a279d097a Signed-off-by: Daniel Erez <derez(a)redhat.com> --- M frontend/webadmin/modules/uicommonweb/src/main/java/org/ovirt/engine/ui/uicommonweb/models/disks/DiskListModel.java M frontend/webadmin/modules/uicommonweb/src/main/java/org/ovirt/engine/ui/uicommonweb/models/storage/SanStorageModel.java M frontend/webadmin/modules/uicommonweb/src/main/java/org/ovirt/engine/ui/uicommonweb/models/vms/VmDiskListModel.java M frontend/webadmin/modules/uicompat/src/main/java/org/ovirt/engine/ui/uicompat/Constants.java M frontend/webadmin/modules/uicompat/src/main/java/org/ovirt/engine/ui/uicompat/Messages.java M frontend/webadmin/modules/webadmin/src/main/java/org/ovirt/engine/ui/webadmin/gin/uicommon/DiskModule.java M frontend/webadmin/modules/webadmin/src/main/java/org/ovirt/engine/ui/webadmin/gin/uicommon/VirtualMachineModule.java 7 files changed, 176 insertions(+), 10 deletions(-) Approvals: Daniel Erez: Verified; Looks good to me, approved -- To view, visit http://gerrit.ovirt.org/7753 To unsubscribe, visit http://gerrit.ovirt.org/settings Gerrit-MessageType: merged Gerrit-Change-Id: I1f303381142d869d162ad6c181dc715a279d097a Gerrit-PatchSet: 2 Gerrit-Project: ovirt-engine Gerrit-Branch: master Gerrit-Owner: Daniel Erez <derez(a)redhat.com> Gerrit-Reviewer: Daniel Erez <derez(a)redhat.com> Gerrit-Reviewer: Gilad Chaplik <gchaplik(a)redhat.com> _______________________________________________ Engine-commits mailing list Engine-commits(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-commits ----boundary_0_521195f1-d75b-475a-8c1a-053655bbd25b Content-Type: application/octet-stream; name="originalBody.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="originalBody.txt" RGFuaWVsIEVyZXogaGFzIHN1Ym1pdHRlZCB0aGlzIGNoYW5nZSBhbmQgaXQgd2FzIG1lcmdlZC4N Cg0KQ2hhbmdlIHN1YmplY3Q6IHdlYmFkbWluOiBEaXJlY3RMVU4gLSBjb25maXJtYXRpb24gZGlh bG9nIGZvciBTRCBMVU4gKCM4NDgwNjcpDQouLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4NCg0KDQp3ZWJhZG1pbjogRGly ZWN0TFVOIC0gY29uZmlybWF0aW9uIGRpYWxvZyBmb3IgU0QgTFVOICgjODQ4MDY3KQ0KDQpodHRw czovL2J1Z3ppbGxhLnJlZGhhdC5jb20vODQ4MDY3DQoNCkRpcmVjdExVTiBkaXNrIC0gd2hlbiBj aG9vc2luZyBhIExVTiB0aGF0IGlzIGFscmVhZHkgcGFydCBvZiBhDQpzdG9yYWdlIGRvbWFpbiwg ZGlzcGxheSBhIHdhcm5pbmcgY29uZmlybWF0aW9uIGRpYWxvZyB3aXRoIGEgbGF0Y2guDQoNCkNo YW5nZS1JZDogSTFmMzAzMzgxMTQyZDg2OWQxNjJhZDZjMTgxZGM3MTVhMjc5ZDA5N2ENClNpZ25l ZC1vZmYtYnk6IERhbmllbCBFcmV6IDxkZXJlekByZWRoYXQuY29tPg0KLS0tDQpNIGZyb250ZW5k L3dlYmFkbWluL21vZHVsZXMvdWljb21tb253ZWIvc3JjL21haW4vamF2YS9vcmcvb3ZpcnQvZW5n aW5lL3VpL3VpY29tbW9ud2ViL21vZGVscy9kaXNrcy9EaXNrTGlzdE1vZGVsLmphdmENCk0gZnJv bnRlbmQvd2ViYWRtaW4vbW9kdWxlcy91aWNvbW1vbndlYi9zcmMvbWFpbi9qYXZhL29yZy9vdmly dC9lbmdpbmUvdWkvdWljb21tb253ZWIvbW9kZWxzL3N0b3JhZ2UvU2FuU3RvcmFnZU1vZGVsLmph dmENCk0gZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxlcy91aWNvbW1vbndlYi9zcmMvbWFpbi9qYXZh L29yZy9vdmlydC9lbmdpbmUvdWkvdWljb21tb253ZWIvbW9kZWxzL3Ztcy9WbURpc2tMaXN0TW9k ZWwuamF2YQ0KTSBmcm9udGVuZC93ZWJhZG1pbi9tb2R1bGVzL3VpY29tcGF0L3NyYy9tYWluL2ph dmEvb3JnL292aXJ0L2VuZ2luZS91aS91aWNvbXBhdC9Db25zdGFudHMuamF2YQ0KTSBmcm9udGVu ZC93ZWJhZG1pbi9tb2R1bGVzL3VpY29tcGF0L3NyYy9tYWluL2phdmEvb3JnL292aXJ0L2VuZ2lu ZS91aS91aWNvbXBhdC9NZXNzYWdlcy5qYXZhDQpNIGZyb250ZW5kL3dlYmFkbWluL21vZHVsZXMv d2ViYWRtaW4vc3JjL21haW4vamF2YS9vcmcvb3ZpcnQvZW5naW5lL3VpL3dlYmFkbWluL2dpbi91 aWNvbW1vbi9EaXNrTW9kdWxlLmphdmENCk0gZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxlcy93ZWJh ZG1pbi9zcmMvbWFpbi9qYXZhL29yZy9vdmlydC9lbmdpbmUvdWkvd2ViYWRtaW4vZ2luL3VpY29t bW9uL1ZpcnR1YWxNYWNoaW5lTW9kdWxlLmphdmENCjcgZmlsZXMgY2hhbmdlZCwgMTc2IGluc2Vy dGlvbnMoKyksIDEwIGRlbGV0aW9ucygtKQ0KDQpBcHByb3ZhbHM6DQogIERhbmllbCBFcmV6OiBW ZXJpZmllZDsgTG9va3MgZ29vZCB0byBtZSwgYXBwcm92ZWQNCg0KDQotLQ0KVG8gdmlldywgdmlz aXQgaHR0cDovL2dlcnJpdC5vdmlydC5vcmcvNzc1Mw0KVG8gdW5zdWJzY3JpYmUsIHZpc2l0IGh0 dHA6Ly9nZXJyaXQub3ZpcnQub3JnL3NldHRpbmdzDQoNCkdlcnJpdC1NZXNzYWdlVHlwZTogbWVy Z2VkDQpHZXJyaXQtQ2hhbmdlLUlkOiBJMWYzMDMzODExNDJkODY5ZDE2MmFkNmMxODFkYzcxNWEy NzlkMDk3YQ0KR2Vycml0LVBhdGNoU2V0OiAyDQpHZXJyaXQtUHJvamVjdDogb3ZpcnQtZW5naW5l DQpHZXJyaXQtQnJhbmNoOiBtYXN0ZXINCkdlcnJpdC1Pd25lcjogRGFuaWVsIEVyZXogPGRlcmV6 QHJlZGhhdC5jb20+DQpHZXJyaXQtUmV2aWV3ZXI6IERhbmllbCBFcmV6IDxkZXJlekByZWRoYXQu Y29tPg0KR2Vycml0LVJldmlld2VyOiBHaWxhZCBDaGFwbGlrIDxnY2hhcGxpa0ByZWRoYXQuY29t Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkVuZ2lu ZS1jb21taXRzIG1haWxpbmcgbGlzdA0KRW5naW5lLWNvbW1pdHNAb3ZpcnQub3JnDQpodHRwOi8v bGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vZW5naW5lLWNvbW1pdHM= ----boundary_0_521195f1-d75b-475a-8c1a-053655bbd25b--

1 0

[Engine-devel] Cancelled: ovirt network
by Livnat Peer 05 Sep '12

05 Sep '12

------=_Part_4104468_1975470803.1346835731287 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit A single instance of the following meeting has been cancelled: Subject: ovirt network Organiser: "Livnat Peer" <lpeer(a)redhat.com> Time: Wednesday, 19 September, 2012, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem Invitees: engine-devel(a)ovirt.org; vdsm-devel(a)lists.fedorahosted.org; GARGYA(a)de.ibm.com; dyasny(a)redhat.com; simon(a)redhat.com; mkolesni(a)redhat.com; atal(a)redhat.com; ilvovsky(a)redhat.com; dfediuck(a)redhat.com; pradipta.banerjee(a)gmail.com; gkotton(a)redhat.com ... *~*~*~*~*~*~*~*~*~* I'm on vacation Sep 19th, cancelling this meeting instance. If you want to have the meeting please send a new invite to the dev lists. Thanks, Livnat ------=_Part_4104468_1975470803.1346835731287 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><body><h3>A single instance of the following meeting has been cancelled:</h3> <table border='0'> <tr><th align=left>Subject:</th><td>ovirt network </td></tr> <tr><th align=left>Organiser:</th><td>"Livnat Peer" <lpeer(a)redhat.com> </td></tr> </table> <table border='0'> <tr><th align=left>Time:</th><td>Wednesday, 19 September, 2012, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem </td></tr></table> <table border='0'> <tr><th align=left>Invitees:</th><td>engine-devel(a)ovirt.org; vdsm-devel(a)lists.fedorahosted.org; GARGYA(a)de.ibm.com; dyasny(a)redhat.com; simon(a)redhat.com; mkolesni(a)redhat.com; atal(a)redhat.com; ilvovsky(a)redhat.com; dfediuck(a)redhat.com; pradipta.banerjee(a)gmail.com; gkotton(a)redhat.com ... </td></tr> </table> <div>*~*~*~*~*~*~*~*~*~*</div> I'm on vacation Sep 19th, cancelling this meeting instance. If you want to have the meeting please send a new invite to the dev lists. Thanks, Livnat</body></html> ------=_Part_4104468_1975470803.1346835731287 Content-Type: text/calendar; charset=utf-8; method=CANCEL; name=meeting.ics Content-Transfer-Encoding: 7bit BEGIN:VCALENDAR PRODID:Zimbra-Calendar-Provider VERSION:2.0 METHOD:CANCEL BEGIN:VTIMEZONE TZID:Asia/Jerusalem BEGIN:STANDARD DTSTART:19710101T020000 TZOFFSETTO:+0200 TZOFFSETFROM:+0300 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=9;BYDAY=4SU TZNAME:IST END:STANDARD BEGIN:DAYLIGHT DTSTART:19710101T020000 TZOFFSETTO:+0300 TZOFFSETFROM:+0200 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1FR TZNAME:IDT END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:cfd70d5d-b663-41f3-b72a-15b532782b23 SUMMARY:Cancelled: ovirt network COMMENT:A single instance of a recurring meeting has been cancelled. ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:engine- devel(a)ovirt.org ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:vdsm-de vel(a)lists.fedorahosted.org ATTENDEE;CN=Tony Gargya/Germany/IBM;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTI ON;RSVP=TRUE:mailto:GARGYA@de.ibm.com ATTENDEE;CN=Dan Yasny;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;RSVP=TRUE:mail to:dyasny@redhat.com ATTENDEE;CN=Simon Grinberg;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE: mailto:simon@redhat.com ATTENDEE;CN=Mike Kolesnik;PARTSTAT=ACCEPTED:mailto:mkolesni@redhat.com ATTENDEE;CN=Avi Tal;PARTSTAT=ACCEPTED:mailto:atal@redhat.com ATTENDEE;CN=Igor Lvovsky;PARTSTAT=ACCEPTED:mailto:ilvovsky@redhat.com ATTENDEE;CN=Doron Fediuck;PARTSTAT=ACCEPTED:mailto:dfediuck@redhat.com ATTENDEE;CN=Pradipta Kumar Banerjee;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED:m ailto:pradipta.banerjee@gmail.com ATTENDEE;CN=Gary Kotton;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED:mailto:gkotto n(a)redhat.com ATTENDEE;CN=Keith Robertson;PARTSTAT=ACCEPTED:mailto:kroberts@redhat.com ATTENDEE;CN=Antoni Segura Puimedon;PARTSTAT=ACCEPTED:mailto:asegurap@redhat. com ATTENDEE;CN=Thang Pham/Poughkeepsie/IBM;SENT-BY="mailto:thang.pham@us.ibm.co m";PARTSTAT=ACCEPTED:mailto:thang.pham@us.ibm.com ORGANIZER;CN=Livnat Peer:mailto:lpeer@redhat.com DTSTART;TZID="Asia/Jerusalem":20120919T160000 DTEND;TZID="Asia/Jerusalem":20120919T170000 STATUS:CANCELLED CLASS:PUBLIC X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY TRANSP:OPAQUE RECURRENCE-ID;TZID="Asia/Jerusalem":20120919T160000 LAST-MODIFIED:20120905T090211Z DTSTAMP:20120905T090211Z SEQUENCE:2 DESCRIPTION:A single instance of the following meeting has been cancelled:\n \nSubject: ovirt network \nOrganiser: "Livnat Peer" <lpeer(a)redhat.com> \n\n Time: Wednesday\, 19 September\, 2012\, 4:00:00 PM - 5:00:00 PM GMT +02:00 J erusalem\n \nInvitees: engine-devel(a)ovirt.org\; vdsm-devel(a)lists.fedorahoste d.org\; GARGYA(a)de.ibm.com\; dyasny(a)redhat.com\; simon(a)redhat.com\; mkolesni@ redhat.com\; atal(a)redhat.com\; ilvovsky(a)redhat.com\; dfediuck(a)redhat.com\; p radipta.banerjee(a)gmail.com\; gkotton(a)redhat.com ... \n\n\n*~*~*~*~*~*~*~*~*~ *\n\nI'm on vacation Sep 19th\, cancelling this meeting instance.\nIf you wa nt to have the meeting please send a new invite to the dev lists.\n\nThanks\ , Livnat X-ALT-DESC;FMTTYPE=text/html:<html><body><h3>A single instance of the follow ing meeting has been cancelled:</h3>\n\n\n<table border='0'>\n<tr><th ali gn=left>Subject:</th><td>ovirt network </td></tr>\n<tr><th align=left>Organ iser:</th><td>"Livnat Peer" &lt\;lpeer(a)redhat.com&gt\; </td></tr>\n</table>\ n\n<table border='0'>\n<tr><th align=left>Time:</th><td>Wednesday\, 19 Se ptember\, 2012\, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem\n </td></tr></ table>\n\n<table border='0'>\n<tr><th align=left>Invitees:</th><td>engine -devel(a)ovirt.org\; vdsm-devel(a)lists.fedorahosted.org\; GARGYA(a)de.ibm.com\; d yasny(a)redhat.com\; simon(a)redhat.com\; mkolesni(a)redhat.com\; atal(a)redhat.com\ ; ilvovsky(a)redhat.com\; dfediuck(a)redhat.com\; pradipta.banerjee(a)gmail.com\; gkotton(a)redhat.com ... </td></tr>\n</table>\n<div>*~*~*~*~*~*~*~*~*~*</div> I'm on vacation Sep 19th\, cancelling this meeting instance. If you wa nt to have the meeting please send a new invite to the dev lists. Tha nks\, Livnat</body></html> END:VEVENT END:VCALENDAR ------=_Part_4104468_1975470803.1346835731287--

1 0