November 2013 - Devel - oVirt List Archives

[Engine-devel] Using REST API in web UI - review call summary
by Vojtech Szocs 14 Feb '14

14 Feb '14

Hi guys, this is a summary of yesterday's review call, I'll try to highlight important Q/A and things we agreed on. Feel free to add anything in case I've missed something. -- Q: Why don't we simply try to use existing Java SDK and adapt it for GWT apps? (asked by Michael & Gilad) A: This might be a viable option to consider if we wanted to skip JavaScript-based SDK altogether and target Java/GWT code directly; we could simply take Java SDK and customize its abstractions where necessary, i.e. using HTTP transport layer implementation that works with GWT. In any case, this would mean coupling ourselves to Java SDK (which has its own release cycle) and I think this would complicate things for us. As proposed on the meeting, I think it's best to aim for JavaScript SDK as the lowest common denominator for *any* web application that wants to work with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, i.e. Java/GWT code that just overlays objects and functions provided by JavaScript SDK. Another reason is ease of maintenance - I'd rather see JavaScript SDK's code generation process to be independent of any other SDK (people responsible for maintaining JavaScript SDK should have full control over generated code). -- Q: What about functionality currently used by oVirt UI but not supported by REST API? (asked by Einav) [For example, fetching VM entity over GWT RPC also returns related data such as Cluster name.] A: Based on discussion I've had with other colleagues after yesterday's review call, I don't think that separate support-like backend layer is a good idea. Instead, this is the kind of functionality that could be placed in oVirt.js library. Logical operations like "get VMs and related data" would be exposed through oVirt.js (callback-based) API and ultimately realized as multiple physical requests to REST API via JavaScript Binding. oVirt.js client would be completely oblivious to the fact that multiple physical requests are dispatched. In fact, since HTTP communication is asynchronous in nature, oVirt.js client wouldn't even notice any difference in terms of API consumption. This assumes JavaScript SDK would use callback-based (non-blocking) API instead of blocking one - after all, blocking API on top of non-blocking implementation sounds pretty much like leaky abstraction [1]. For example: sdk.getVmsWithExtraData( callbackToGetExtraDataForGivenVm, // might cause extra physical requests to REST API callbackFiredWhenAllDataIsReady // update client only when all data is ready ) [1] http://en.wikipedia.org/wiki/Leaky_abstraction -- Last but not least, where to maintain JavaScript SDK projects: low-level JavaScript Binding + high-level oVirt.js library. I agree that conceptually both above mentioned projects should go into dedicated "ovirt-engine-sdk-js" git repository and have their own build/release process. However, for now, we're just making baby steps so let's keep things simple and prototype these projects as part of "ovirt-engine" git repository. ... we can complicate things anytime, but we should know that any complex system that works has inevitably evolved from simple system that works ... (quote from http://en.wikipedia.org/wiki/Gall%27s_law) Regards, Vojtech

4 17

[Engine-devel] ovirt-engine-sdk-java 1.0.0.6-1 released
by Michael Pasternak 25 Dec '13

25 Dec '13

- added new collection ClusterGlusterVolumeGlusterBrickStatistics - added new properties to the GlusterBrick - to vm added cpu.mode - to host install action added "image" parameter - ignore case in factory method lookup More details can be found at [1]. [1] http://www.ovirt.org/Java-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization R&D

1 10

[Engine-devel] ovirt-sdk-python 3.3.0.1 released
by Michael Pasternak 25 Dec '13

25 Dec '13

- added new collection ClusterGlusterVolumeBrickStatistics - added NetUp 'cloned disk' importing capabilities - to ClusterGlusterVolumeBricks.list() added new argument "all_content" - to ClusterGlusterVolumeBricks.get() added new argument "all_content" - to host install method added new parameter "image" - to host add method added new parameter "display.address" - to vm add method added new parameter "vm.cpu.mode" - to vm add method added new overload for creating vm from snapshot - to cluster added tunnel_migration - to display added keyboard_layout - to display added smartcard_enabled - to DataCenter added Clusters sub-collection - to StorageDomain added Disks sub-collection - to Disks.list() added 'unregistered' argument - to Host added display.address - to Snapshot added commit/preview/undo actions - to vms.add() added overload for creating vm from snapshot - to hosts.add() added [@param host.display.address: string] - to vm.ticket() added [@param action.ticket.value: string] - return error if amount of fetched objects in X.get() is > 1 #890327 - session based authentication for /localhost is broken #916285 - explicitly ask for reply in xml - Add constructor parameter validate_cert_chain=True #915225 - defend against malformed server reply For more details see [1]. [1] http://wiki.ovirt.org/Python-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization R&D

1 5

[Engine-devel] GUI widget for adding/removing entries
by Lior Vernia 17 Dec '13

17 Dec '13

Hello, Lately a patch has been merged that introduces a widget for adding/removing entries (e.g. network interfaces when creating/editing a VM): http://gerrit.ovirt.org/#/c/19530/ This kind of widgets is becoming common in oVirt, so the idea is to make adding one easy rather than copying & pasting code. AddRemoveRowWidget takes care of the plus/minus button logic, disabling an entry that hasn't been edited, and the arranging in rows. In order to use it, one is required to override a couple of abstract methods that are dependent upon the specific entry implementation. An example may be found in ProfilesInstanceTypeEditor, which handles adding/removing network interfaces in the new/edit VM dialog. Yours, Lior.

4 14

[Engine-devel] Using config values
by Kanagaraj 04 Dec '13

04 Dec '13

This is a multi-part message in MIME format. --------------050008020702070900040001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi All, The are some issues arising in configurations whenever we move up on the versions(3.3 => 3.4), because of the way we store and interpret them. Whenever there is a new cluster level, you will need to add a new entry for all(most) of the configuration. Mostly a copy paste if you see from 3.2 to 3.3, except some CPU/PM type related configurations. Better option would be to have the defaul config value in ConfigValues.java and the overrides will go to config.sql. In this approach you don't need a new entries to config.sql when there is a new cluster level. Lets take an exmaple, "SupportForceCreateVG" - This is supported from 3.1 onwards, If you look at config.sql, you will see following entries select fn_db_add_config_value('SupportForceCreateVG','false','3.0'); select fn_db_add_config_value('SupportForceCreateVG','true','3.1'); select fn_db_add_config_value('SupportForceCreateVG','true','3.2'); select fn_db_add_config_value('SupportForceCreateVG','true','3.3'); And in ConfigValues.java @TypeConverterAttribute(Boolean.class) @DefaultValueAttribute("false") SupportForceCreateVG, Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which i feel is redundant. Instead we can make @TypeConverterAttribute(Boolean.class) @DefaultValueAttribute("true") SupportForceCreateVG, and have only the following in config.sql select fn_db_add_config_value('SupportForceCreateVG','false','3.0'); if a particular value(for a specific cluster level) is not found in Config.sql, the fallback is to use the value available in ConfigValues.java. Please share your thoughts on this. Thanks, Kanagaraj --------------050008020702070900040001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi All,<br> <br> The are some issues arising in configurations whenever we move up on the versions(3.3 => 3.4), because of the way we store and interpret them.<br> <br> Whenever there is a new cluster level, you will need to add a new entry for all(most) of the configuration. Mostly a copy paste if you see from 3.2 to 3.3, except some CPU/PM type related configurations.<br> Better option would be to have the defaul config value in ConfigValues.java and the overrides will go to config.sql. In this approach you don't need a new entries to config.sql when there is a new cluster level.<br> <br> Lets take an exmaple, "SupportForceCreateVG" - This is supported from 3.1 onwards,<br> <br> If you look at config.sql, you will see following entries <br> select fn_db_add_config_value('SupportForceCreateVG','false','3.0'); <br> select fn_db_add_config_value('SupportForceCreateVG','true','3.1'); <br> select fn_db_add_config_value('SupportForceCreateVG','true','3.2'); <br> select fn_db_add_config_value('SupportForceCreateVG','true','3.3');<br> <br> And in ConfigValues.java<br> <br>     @TypeConverterAttribute(Boolean.class)<br>     @DefaultValueAttribute("false")<br>     SupportForceCreateVG,<br> <br> Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which i feel is redundant.<br> <br> Instead we can make <br> <br>     @TypeConverterAttribute(Boolean.class)<br>     @DefaultValueAttribute("true")<br>     SupportForceCreateVG,<br> <br> and have only the following in config.sql<br> select fn_db_add_config_value('SupportForceCreateVG','false','3.0');<br> <br> if a particular value(for a specific cluster level) is not found in Config.sql, the fallback is to use the value available in ConfigValues.java.<br> <br> Please share your thoughts on this.<br> <br> Thanks,<br> Kanagaraj<br> <br> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </body> </html> --------------050008020702070900040001--

8 13

[Engine-devel] Remove Comment column in main tabs
by Mike Kolesnik 02 Dec '13

02 Dec '13

------=_Part_40758794_854245147.1385448274314 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, When the comment RFE was added (in 3.3), there was also a column added to many main tabs. I would like to propose to get rid of the column (which can only house one icon or no icon), and instead if there's a comment on an entity just display the icon with the tooltip adjacent to the name. In this case the icon should probably be scaled down a bit since its huge. I think this would be a good alternative and save us some valued screen real estate. Thoughts, opinions? Regards, Mike ------=_Part_40758794_854245147.1385448274314 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><div>Hi,<br></div><div><br></div><div>When the comment RFE was added (in 3.3), there was also a column added to many main tabs.<br></div><div><br></div><div>I would like to propose to get rid of the column (which can only house one icon or no icon),</div><div>and instead if there's a comment on an entity just display the icon with the tooltip adjacent to the name.<br></div><div><br></div><div>In this case the icon should probably be scaled down a bit since its huge.<br></div><div><br></div><div>I think this would be a good alternative and save us some valued screen real estate.<br></div><div><br></div><div>Thoughts, opinions?<br></div><div><br></div><div><span name="x"></span>Regards,<br>Mike<span name="x"></span><br></div><div><br></div></div></body></html> ------=_Part_40758794_854245147.1385448274314--

5 16

[Engine-devel] [ANN] new fedora20 nightlies rpms for oVirt are available for download
by Eyal Edri 30 Nov '13

30 Nov '13

fyi, oVirt infra has added support for nighlies rpms for various oVirt projects for fedora 20. the following has be done: - All ovirt projects were added f20 nightlies on jenkins.ovirt.org. (replaced f18, which is NOT built nightly anymore). - One jenkins f19 slave (vm02) was upgraded to f20, and we also have a bare metal host running f20 as well. - Nightlies rpms can be downloaded on the repos [1] - Nightlies publish & cleanup scripts were updated on the resources.ovirt.org to support f20. I didn't update any ovirt-node* job, since i'm not familiar with them. if you would like to build f20 builds, just add the 'fedora20' label to the relevant jobs. Eyal. [1] http://resources.ovirt.org/releases/nightly/rpm/Fedora/20/

1 0

Re: [Engine-devel] Fedora 20 support, Was: [Users] oVirt Weekly Meeting Minutes -- 2013-11-27
by Eyal Edri 30 Nov '13

30 Nov '13

I updated the environment to support f20, including new slave and nighlites. i will send a separate email on it soon to infra/users/devel. Eyal. ----- Original Message ----- > From: "Doron Fediuck" <dfediuck(a)redhat.com> > To: "Dan Kenigsberg" <danken(a)redhat.com>, "David Caro Estevez" <dcaroest(a)redhat.com> > Cc: board(a)ovirt.org, "users" <users(a)ovirt.org>, eedri(a)redhat.com, "Sandro Bonazzola" <sbonazzo(a)redhat.com> > Sent: Thursday, November 28, 2013 1:55:13 PM > Subject: Re: Fedora 20 support, Was: [Users] oVirt Weekly Meeting Minutes -- 2013-11-27 > > > > ----- Original Message ----- > > From: "Dan Kenigsberg" <danken(a)redhat.com> > > To: board(a)ovirt.org, "users" <users(a)ovirt.org> > > Cc: "Doron Fediuck" <dfediuck(a)redhat.com>, eedri(a)redhat.com > > Sent: Thursday, November 28, 2013 12:19:05 PM > > Subject: Fedora 20 support, Was: [Users] oVirt Weekly Meeting Minutes -- > > 2013-11-27 > > > > We've forgotten to discuss an important issue: Fedora 20, which is > > expected to be out in two weeks: > > http://fedoraproject.org/wiki/Releases/20/Schedule. > > I believe that ovirt-3.4 must support it, and that ovirt-3.3.2 would > > better do so. > > > > Toni has fixed two issues regarding Vdsm-networking, and they are going > > into ovirt-3.3.2 beta. However, we must perform much more comprehensive > > testing. > > > > We'd need to have f20 Jenkins slave(s), and someone in each team > > responsible to testing functionality. Who can cover for storage, virt, > > infra and integration? > > > > Dan. > > > > Indeed so, thanks Dan. > David, is this something we have resources for? >

1 0

Re: [Engine-devel] [Users] oVirt Weekly Meeting Minutes -- 2013-11-27
by Sandro Bonazzola 29 Nov '13

29 Nov '13

Il 29/11/2013 13:13, Dan Kenigsberg ha scritto: > On Fri, Nov 29, 2013 at 11:49:59AM +0100, Sandro Bonazzola wrote: >> Il 29/11/2013 09:43, Gianluca Cecchi ha scritto: >>> On Fri, Nov 29, 2013 at 8:57 AM, Sandro Bonazzola wrote: >>> >>>>> >>>>> Meeting summary >>>>> --------------- >>>>> * Agenda and roll Call (doron, 15:02:42) >>>>> * 3.3 update releases (doron, 15:04:23) >>>>> * 3.4 planning (doron, 15:04:24) >>>>> * conferences and workshops (doron, 15:04:26) >>>>> * infra update (doron, 15:04:27) >>>>> * other topics (doron, 15:04:29) >>>>> * LINK: http://gerrit.ovirt.org/#/admin/projects/ovirt-release ~ >>>>> (danken, 15:12:58) >>>>> * LINK: http://gerrit.ovirt.org/21794 (mburns, 15:15:04) >>>>> * LINK: http://jenkins.ovirt.org/job/ovirt-release/16800/ (mburns, >>>>> 15:15:48) >>>>> * mburns to add sbonazzo as a maintainer to support ovirt-release >>>>> project (doron, 15:18:17) >>>> >>>> ovirt-release-9 released yesterday >>> >>> BTW: I see that this package contains >>> /etc/yum.repos.d/fedora-virt-preview.repo >>> (and ovirt-release-fedora-8-1.noarch already did so) >>> By default all lines are disabled in it. >>> When and how this repo should be enabled? Only when using nightly or >>> only under developers/maintainers indications? >> >> I think that fedora-virt-preview should be used with nightly, stable shouldn't need it. >> However, since fedora-virt-preview contains vdsm - related packages not needed if you run only ovirt-engine (without using the same host as >> hypervisor) I think it's better to wait for VDSM guys answer. > > Vdsm is not in > http://fedorapeople.org/groups/virt/virt-preview/fedora-20/x86_64/ > > virt-preview is not needed for ovirt-3.3, and frankly, I think it should > be dropped from ovirt-release. > > It used to be needed on the nodes when vdsm required a version of > libvirt that was not yet in Fedora. Now that we have el6 as a > fully-supported platform, and given that el6 is missing from > virt-preview, virt-preview is much less helpful to us. > > Dan. > So, any objection in removing virt-preview from ovirt-release? What about nightly? Will it be needed there? -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1

Re: [Engine-devel] Weird behavior of multiple SetVmTicket query
by Vojtech Szocs 28 Nov '13

28 Nov '13

------=_Part_22230002_1751095465.1384256418493 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Forwarding this email to engine-devel so that backend maintainers are aware of this issue. Looking at the code: - MultipleActionsRunner#Execute first creates and "validates" all commands: A. the "for" block which iterates over getParameters() 1-> validate correlation ID, if OK create and add command, otherwise add returnValue B the "if" block which tests getCommands().size() 1-> if single command to execute, add its "canDoActionOnly" returnValue, which is returnValue with canDoAction but without actual result object 2-> if multi commands to execute, execute chunks of max. 10 threads (sequentially, ThreadPoolUtil.invokeAll returns after all threads complete), same returnValue as above C. the "if" block which tests canRunActions 1-> all commands are executed within SINGLE THREAD due to ThreadPoolUtil.execute(Runnable), which is kind of weird comapred to how returnValues are prepared (see B2) 2-> when executing command, code DOES NOT CARE about its returnValue, i.e. returnValue was already prepared (see B) and command execution should just update it The problem (I think) is that C1 starts a different thread (to execute all commands) and immediately returns, i.e. code doesn't wait for thread to complete. This is why returnValues are observed on frontend as inconsistent. Additionally, we're also mixing of two different things: canDoAction processing and returnValues processing. IMHO this should be refactored to make code easier to read. Changes done by Alex (patch attached): X1. returnValues changed to Collections.synchronizedList -> this means all access to returnValues is now serial -> iteration over synchronizedList should also be enclosed in "synchronized (list)" block, so this: for (VdcReturnValueBase value : returnValues) ... should be this: synchronized (returnValues) { for (VdcReturnValueBase value : returnValues) ... } X2. commented-out original command execution via ThreadPoolUtil.execute(Runnable) -> new RunCommands method invokes all commands each in separate thread via ThreadPoolUtil.invokeAll -> returnValues list is explicitly updated Guys, what do you think? Vojtech ----- Original Message ----- > From: "Alexander Wels" <awels(a)redhat.com> > To: "Frantisek Kobzik" <fkobzik(a)redhat.com> > Cc: "Vojtech Szocs" <vszocs(a)redhat.com> > Sent: Monday, November 11, 2013 9:19:08 PM > Subject: Re: Weird behavior of multiple SetVmTicket query > > Hi, > > I did some debugging, and the problem is a race condition in the > MultipleActions class. The whole class seems to have a lot of multi-threading > issues but if I modify the code to wait for the results of the actions to > return before returning the return value, everything works fine. > > I am attaching a patch that solves the issue at hand, but should not be > considered a real patch. It is just to show the issue is in the back-end not > the front-end code. The front-end code is just exposing an issue in the back- > end > > Alexander > > On Monday, November 11, 2013 09:53:22 AM you wrote: > > Ok, thank you very much! > > > > ----- Original Message ----- > > From: "Alexander Wels" <awels(a)redhat.com> > > To: "Frantisek Kobzik" <fkobzik(a)redhat.com> > > Sent: Monday, November 11, 2013 2:15:43 PM > > Subject: Re: Weird behavior of multiple SetVmTicket query > > > > Frantisek, > > > > I had seen this before, let me test and fix it for you, it is very likely > > my > > patch broke that. > > > > Alexander > > > > On Monday, November 11, 2013 03:43:19 AM you wrote: > > > Hi Alex, > > > > > > recently I noticed problems with invoking console for multiple VMs > > > (select > > > more VMs in webadmin and then hit the console btn). I was sure it worked > > > in > > > past so i git-bisected the master branch and I discovered that this > > > problem > > > is apparently caused by patch [1]. For single vm console invocation it > > > works fine, but for multiple VMs it doesn't. > > > > > > I did some closer investigation with a debugger and it seems that > > > getSucceeded() on the return val of SetVmTicket command returns false in > > > case of multiple execution despite the fact SetVmTicketCommand sets this > > > value to true. I suppose there is some problem with propagation of > > > command > > > return value from BE to FE. The same goes for the encapsulated > > > returnValue > > > attribute (it contains value of the generated ticket). When invoking > > > multiple consoles it is null (although it has been filled on backend). > > > Weird. > > > > > > Tomas told me you did some optimizations for multiple command executions, > > > do you know it might cause it? Please let me know if you have any idea... > > > > > > Cheers, > > > F. > > > > > > [1]: http://gerrit.ovirt.org/#/c/17356/ > ------=_Part_22230002_1751095465.1384256418493 Content-Type: text/x-patch; name=thread_wait.patch Content-Disposition: attachment; filename=thread_wait.patch Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2JhY2tlbmQvbWFuYWdlci9tb2R1bGVzL2JsbC9zcmMvbWFpbi9qYXZhL29y Zy9vdmlydC9lbmdpbmUvY29yZS9ibGwvTXVsdGlwbGVBY3Rpb25zUnVubmVyLmphdmEgYi9iYWNr ZW5kL21hbmFnZXIvbW9kdWxlcy9ibGwvc3JjL21haW4vamF2YS9vcmcvb3ZpcnQvZW5naW5lL2Nv cmUvYmxsL011bHRpcGxlQWN0aW9uc1J1bm5lci5qYXZhDQppbmRleCBhNzJmYmQ5Li4xYjRmNGRh IDEwMDY0NA0KLS0tIGEvYmFja2VuZC9tYW5hZ2VyL21vZHVsZXMvYmxsL3NyYy9tYWluL2phdmEv b3JnL292aXJ0L2VuZ2luZS9jb3JlL2JsbC9NdWx0aXBsZUFjdGlvbnNSdW5uZXIuamF2YQ0KKysr IGIvYmFja2VuZC9tYW5hZ2VyL21vZHVsZXMvYmxsL3NyYy9tYWluL2phdmEvb3JnL292aXJ0L2Vu Z2luZS9jb3JlL2JsbC9NdWx0aXBsZUFjdGlvbnNSdW5uZXIuamF2YQ0KQEAgLTEsNiArMSw3IEBA DQogcGFja2FnZSBvcmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsOw0KIA0KIGltcG9ydCBqYXZhLnV0 aWwuQXJyYXlMaXN0Ow0KK2ltcG9ydCBqYXZhLnV0aWwuQ29sbGVjdGlvbnM7DQogaW1wb3J0IGph dmEudXRpbC5MaXN0Ow0KIGltcG9ydCBqYXZhLnV0aWwuY29uY3VycmVudC5DYWxsYWJsZTsNCiAN CkBAIC0yMCw3ICsyMSw3IEBAIHB1YmxpYyBjbGFzcyBNdWx0aXBsZUFjdGlvbnNSdW5uZXIgew0K ICAgICBwcml2YXRlIGZpbmFsIHN0YXRpYyBpbnQgQ09OQ1VSUkVOVF9BQ1RJT05TID0gMTA7DQog DQogICAgIHByaXZhdGUgVmRjQWN0aW9uVHlwZSBfYWN0aW9uVHlwZSA9IFZkY0FjdGlvblR5cGUu VW5rbm93bjsNCi0gICAgcHJpdmF0ZSBMaXN0PFZkY0FjdGlvblBhcmFtZXRlcnNCYXNlPiBfcGFy YW1ldGVyczsNCisgICAgcHJpdmF0ZSBmaW5hbCBMaXN0PFZkY0FjdGlvblBhcmFtZXRlcnNCYXNl PiBfcGFyYW1ldGVyczsNCiAgICAgcHJpdmF0ZSBmaW5hbCBBcnJheUxpc3Q8Q29tbWFuZEJhc2U8 Pz4+IF9jb21tYW5kcyA9IG5ldyBBcnJheUxpc3Q8Q29tbWFuZEJhc2U8Pz4+KCk7DQogICAgIHBy b3RlY3RlZCBib29sZWFuIGlzSW50ZXJuYWw7DQogDQpAQCAtNTUsNyArNTYsNyBAQCBwdWJsaWMg Y2xhc3MgTXVsdGlwbGVBY3Rpb25zUnVubmVyIHsNCiAgICAgICAgICAgICByZXR1cm4gbmV3IEFy cmF5TGlzdDxWZGNSZXR1cm5WYWx1ZUJhc2U+KCk7DQogICAgICAgICB9DQogDQotICAgICAgICBB cnJheUxpc3Q8VmRjUmV0dXJuVmFsdWVCYXNlPiByZXR1cm5WYWx1ZXMgPSBuZXcgQXJyYXlMaXN0 PFZkY1JldHVyblZhbHVlQmFzZT4oKTsNCisgICAgICAgIEFycmF5TGlzdDxWZGNSZXR1cm5WYWx1 ZUJhc2U+IHJldHVyblZhbHVlcyA9IChBcnJheUxpc3Q8VmRjUmV0dXJuVmFsdWVCYXNlPikgQ29s bGVjdGlvbnMuc3luY2hyb25pemVkTGlzdChuZXcgQXJyYXlMaXN0PFZkY1JldHVyblZhbHVlQmFz ZT4oKSk7DQogICAgICAgICB0cnkgew0KICAgICAgICAgICAgIFZkY1JldHVyblZhbHVlQmFzZSBy ZXR1cm5WYWx1ZTsNCiAgICAgICAgICAgICBmb3IgKFZkY0FjdGlvblBhcmFtZXRlcnNCYXNlIHBh cmFtZXRlciA6IGdldFBhcmFtZXRlcnMoKSkgew0KQEAgLTg4LDEyICs4OSwxMiBAQCBwdWJsaWMg Y2xhc3MgTXVsdGlwbGVBY3Rpb25zUnVubmVyIHsNCiAgICAgICAgICAgICB9DQogDQogICAgICAg ICAgICAgaWYgKGNhblJ1bkFjdGlvbnMpIHsNCi0gICAgICAgICAgICAgICAgVGhyZWFkUG9vbFV0 aWwuZXhlY3V0ZShuZXcgUnVubmFibGUoKSB7DQotICAgICAgICAgICAgICAgICAgICBAT3ZlcnJp ZGUNCi0gICAgICAgICAgICAgICAgICAgIHB1YmxpYyB2b2lkIHJ1bigpIHsNCi0gICAgICAgICAg ICAgICAgICAgICAgICBSdW5Db21tYW5kcygpOw0KLSAgICAgICAgICAgICAgICAgICAgfQ0KLSAg ICAgICAgICAgICAgICB9KTsNCisvLyAgICAgICAgICAgICAgICBUaHJlYWRQb29sVXRpbC5leGVj dXRlKG5ldyBSdW5uYWJsZSgpIHsNCisvLyAgICAgICAgICAgICAgICAgICAgQE92ZXJyaWRlDQor Ly8gICAgICAgICAgICAgICAgICAgIHB1YmxpYyB2b2lkIHJ1bigpIHsNCisgICAgICAgICAgICAg ICAgICAgICAgICBSdW5Db21tYW5kcyhyZXR1cm5WYWx1ZXMpOw0KKy8vICAgICAgICAgICAgICAg ICAgICB9DQorLy8gICAgICAgICAgICAgICAgfSk7DQogICAgICAgICAgICAgfQ0KICAgICAgICAg fSBjYXRjaCAoUnVudGltZUV4Y2VwdGlvbiBlKSB7DQogICAgICAgICAgICAgbG9nLmVycm9yKCJG YWlsZWQgdG8gZXhlY3V0ZSBtdWx0aXBsZSBhY3Rpb25zIG9mIHR5cGU6ICIgKyBfYWN0aW9uVHlw ZSwgZSk7DQpAQCAtMTMyLDYgKzEzMywxNiBAQCBwdWJsaWMgY2xhc3MgTXVsdGlwbGVBY3Rpb25z UnVubmVyIHsNCiAgICAgICAgIH07DQogICAgIH0NCiANCisgICAgcHJvdGVjdGVkIENhbGxhYmxl PFZkY1JldHVyblZhbHVlQmFzZT4gYnVpbGRBY3Rpb25Bc3luYyhmaW5hbCBDb21tYW5kQmFzZTw/ PiBjb21tYW5kKSB7DQorICAgICAgICByZXR1cm4gbmV3IENhbGxhYmxlPFZkY1JldHVyblZhbHVl QmFzZT4oKSB7DQorDQorICAgICAgICAgICAgQE92ZXJyaWRlDQorICAgICAgICAgICAgcHVibGlj IFZkY1JldHVyblZhbHVlQmFzZSBjYWxsKCkgew0KKyAgICAgICAgICAgICAgICByZXR1cm4gZXhl Y3V0ZVZhbGlkYXRlZENvbW1hbmQyKGNvbW1hbmQpOw0KKyAgICAgICAgICAgIH0NCisgICAgICAg IH07DQorICAgIH0NCisNCiAgICAgcHJvdGVjdGVkIFZkY1JldHVyblZhbHVlQmFzZSBydW5DYW5E b0FjdGlvbk9ubHkoZmluYWwgaW50IGN1cnJlbnRDYW5Eb0FjdGlvbklkLCBmaW5hbCBpbnQgdG90 YWxTaXplKSB7DQogICAgICAgICBDb21tYW5kQmFzZTw/PiBjb21tYW5kID0gZ2V0Q29tbWFuZHMo KS5nZXQoY3VycmVudENhbkRvQWN0aW9uSWQpOw0KICAgICAgICAgU3RyaW5nIGFjdGlvblR5cGUg PSBjb21tYW5kLmdldEFjdGlvblR5cGUoKS50b1N0cmluZygpOw0KQEAgLTE1OCw2ICsxNjksMTYg QEAgcHVibGljIGNsYXNzIE11bHRpcGxlQWN0aW9uc1J1bm5lciB7DQogICAgICAgICB9DQogICAg IH0NCiANCisgICAgcHJvdGVjdGVkIHZvaWQgUnVuQ29tbWFuZHMoQXJyYXlMaXN0PFZkY1JldHVy blZhbHVlQmFzZT4gcmV0dXJuVmFsdWVzKSB7DQorICAgICAgICBMaXN0PENhbGxhYmxlPFZkY1Jl dHVyblZhbHVlQmFzZT4+IGFjdGlvblRhc2tzID0gbmV3IEFycmF5TGlzdDxDYWxsYWJsZTxWZGNS ZXR1cm5WYWx1ZUJhc2U+PigpOw0KKyAgICAgICAgZm9yIChDb21tYW5kQmFzZTw/PiBjb21tYW5k IDogZ2V0Q29tbWFuZHMoKSkgew0KKyAgICAgICAgICAgIGlmIChjb21tYW5kLmdldFJldHVyblZh bHVlKCkuZ2V0Q2FuRG9BY3Rpb24oKSkgew0KKyAgICAgICAgICAgICAgICBhY3Rpb25UYXNrcy5h ZGQoYnVpbGRBY3Rpb25Bc3luYyhjb21tYW5kKSk7DQorICAgICAgICAgICAgfQ0KKyAgICAgICAg fQ0KKyAgICAgICAgcmV0dXJuVmFsdWVzLmFkZEFsbChUaHJlYWRQb29sVXRpbC5pbnZva2VBbGwo YWN0aW9uVGFza3MpKTsNCisgICAgfQ0KKw0KICAgICAvKioNCiAgICAgICogRXhlY3V0ZXMgY29t bWFuZHMgd2hpY2ggcGFzc2VkIHZhbGlkYXRpb24gYW5kIGNyZWF0ZXMgbW9uaXRvcmluZyBvYmpl Y3RzLg0KICAgICAgKg0KQEAgLTE3NSw2ICsxOTYsMTcgQEAgcHVibGljIGNsYXNzIE11bHRpcGxl QWN0aW9uc1J1bm5lciB7DQogICAgICAgICBjb21tYW5kLmV4ZWN1dGVBY3Rpb24oKTsNCiAgICAg fQ0KIA0KKyAgICBwcm90ZWN0ZWQgVmRjUmV0dXJuVmFsdWVCYXNlIGV4ZWN1dGVWYWxpZGF0ZWRD b21tYW5kMihDb21tYW5kQmFzZTw/PiBjb21tYW5kKSB7DQorICAgICAgICBpZiAoZXhlY3V0aW9u Q29udGV4dCA9PSBudWxsIHx8IGV4ZWN1dGlvbkNvbnRleHQuaXNNb25pdG9yZWQoKSkgew0KKyAg ICAgICAgICAgIEV4ZWN1dGlvbkhhbmRsZXIucHJlcGFyZUNvbW1hbmRGb3JNb25pdG9yaW5nKGNv bW1hbmQsDQorICAgICAgICAgICAgICAgICAgICBjb21tYW5kLmdldEFjdGlvblR5cGUoKSwNCisg ICAgICAgICAgICAgICAgICAgIGNvbW1hbmQuaXNJbnRlcm5hbEV4ZWN1dGlvbigpKTsNCisgICAg ICAgIH0NCisgICAgICAgIFRocmVhZExvY2FsUGFyYW1zQ29udGFpbmVyLnNldENvcnJlbGF0aW9u SWQoY29tbWFuZC5nZXRDb3JyZWxhdGlvbklkKCkpOw0KKyAgICAgICAgY29tbWFuZC5pbnNlcnRB c3luY1Rhc2tQbGFjZUhvbGRlcnMoKTsNCisgICAgICAgIHJldHVybiBjb21tYW5kLmV4ZWN1dGVB Y3Rpb24oKTsNCisgICAgfQ0KKw0KICAgICBwdWJsaWMgdm9pZCBzZXRFeGVjdXRpb25Db250ZXh0 KEV4ZWN1dGlvbkNvbnRleHQgZXhlY3V0aW9uQ29udGV4dCkgew0KICAgICAgICAgdGhpcy5leGVj dXRpb25Db250ZXh0ID0gZXhlY3V0aW9uQ29udGV4dDsNCiAgICAgfQ0K ------=_Part_22230002_1751095465.1384256418493--

5 7

[Engine-devel] oVirt Weekly Meeting Minutes
by Leonardo Bianconi 28 Nov '13

28 Nov '13

Hi Sandro These are the PPC features and its status: Target Status Description 3.4 - Under review - Architecture support when importing/exporting VM and Templates 3.4 - Under review - Ability to specify architecture in the OSInfo file 3.4 - Under review - Ability to specify supported video cards and display protocols in the OSInfo file 3.4 - Under review - Ability to specify watch dog in the OSInfo file 3.4 - Done - Ability to specify hotplug of nic and disk in the OSInfo file 3.4 - Under review - Ability to search by architecture 3.4 - Under review - Create Cluster, VM and Templates for PPC64 3.4 - Under review - Add PPC64 Hosts 3.4 - Under review - Support for sPAPR VLAN and sPAPR VSCSI 3.4 - Under review - Run fake power hosts 3.4 - Under review - Obtain capabilities of PPC64 hosts 3.4 - Under review - Obtain the CPU topology of PPC64 hosts 3.4 - Under review - Ability to run power machines on x86 hosts Some basic patches for PPC support were merged but not enough to enable any PPC feature. We are focused on the patches 18938, 19010 and 18220 (see below), since they are the base for all PPC features. Engine 18938 (Initial support for alternative architectures) |_19010 (Architecture parameter on search backend) |_18220 (New OS for IBM POWER support) |_21503 (Architecture dependent commands) |_21522 (Avoid migration in ppc64) 20294 (Architecture dependent commands) |_18622 (sPAPR SCSI on PPC64 VMs) |_20630 (Limit the number of SCSI and VirtIO blk devices) |_17972 (Show only compatible OSes) |_18347 (OS type validation) |_20667 (Fix VM creation with blank template) |_18702 (Fill and check arch when importing VM and Template) |_19012 (OVF import for multiple architectures) |_18226 (Cluster and arch related changes) |_19132 (Prevent arch mismatches in the FE) |_18227 (Added arch support for VM and Template) |_19487 (Selection of incompatible templates) VDSM 19395 (Hardware information about POWER hosts) |_17437 (Adding ppc64 handling to getVdsCaps) |_19396 (Report fake capabilities) |_18718 (Create VMs for the POWER architecture) |_19875 (Handling topology for ppc64) Regards Leonardo Bianconi Date: Wed, 27 Nov 2013 17:14:37 +0100 From: Sandro Bonazzola <sbonazzo(a)redhat.com> To: "Users(a)ovirt.org" <Users(a)ovirt.org>, engine-devel <engine-devel(a)ovirt.org> Subject: [Engine-devel] oVirt PPC status update Message-ID: <52961A6D.4090208(a)redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Hi, anybody can report about PPC status for 3.3.2 and 3.4.0 target releases? It would be nice having someone for PPC at ovirt-sync meeting from next week on, so please join :-) Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

[Engine-devel] [QE] oVirt 3.3.2 beta status
by Sandro Bonazzola 28 Nov '13

28 Nov '13

Hi, we're going to branch and build oVirt 3.3.2 beta TODAY. A bug tracker is available at [1] and it shows only 3 bugs still blocking the release: Whiteboard Bug ID Summary storage 1022961 Running a VM from a gluster domain uses mount instead of gluster URI virt 1025829 sysprep floppy is not attached to Windows 2008 R2 machine - even when specifically checked in Run Once virt 1029885 cloud-init testcase does not work in engine 3.3.1 Please provide an ETA for the above bugs. The following is a list of the non-blocking bugs still open with target 3.3.2: Whiteboard Bug ID Summary infra 1017267 Plaintext user passwords in async_tasks database infra 987982 When adding a host through the REST API, the error message says that "rootPassword" is required,... infra 1020344 Power Managent with cisco_ucs problem integration 1022440 AIO - configure the AIO host to be a gluster cluster/host integration 902979 ovirt-live - firefox doesn't trust the installed engine integration 1021805 oVirt Live - use motd to show the admin password integration 1026930 Package virtio-win and put it in ovirt repositories integration 1026933 pre-populate ISO domain with virtio-win ISO network 1019818 Support OpenStack Havana layer 2 agent integration network 987999 [oVirt] [provider] Add button shouldn't appear on specific provider network 987916 [oVirt] [provider] Dialog doesn't update unless focus lost network 906313 [oVirt-webadmin] [setupNetworks] "No valid Operation for <network_name> and Unassigned Logical Networks panel" network 1023722 [oVirt-webadmin][network] Network roles in cluster management should be radio buttons network 997197 Some AppErrors messages are grammatically incorrect (singular vs plural) storage 1029069 Live storage migration snapshot removal fails, probably due to unexpected qemu-img output storage 987917 [oVirt] [glance] API version not specified in provider dialog storage 1016118 async between masterVersion : can't connect to StoragePool ux 906394 [oVirt-webadmin] [network] Loading animation in network main tab 'hosts' and 'vms' subtab is stuck on first view... virt 1007940 Cannot clone from snapshot while using GlusterFS as POSIX Storage Domain Please add the bugs to the tracker if you think that 3.3.2 should not be released without them fixed. For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug and add yourself to the testing page [2]. Maintainers are welcomed to start filling release notes, the page has been created here [3] [1] https://bugzilla.redhat.com/1027349 [2] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing [3] http://www.ovirt.org/OVirt_3.3.2_release_notes Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

4 3

[Engine-devel] oVirt PPC status update
by Sandro Bonazzola 27 Nov '13

27 Nov '13

Hi, anybody can report about PPC status for 3.3.2 and 3.4.0 target releases? It would be nice having someone for PPC at ovirt-sync meeting from next week on, so please join :-) Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Re: [Engine-devel] [vdsm] Multiple graphics framebuffers - VDSM support
by Frantisek Kobzik 27 Nov '13

27 Nov '13

Hi guys, I created a wiki page with the feature: http://www.ovirt.org/Features/Multiple_Consoles It contains information about possible redesign of Engine<->VDSM communication. I'd appreciate if you take a look at it since it's not trivial change. I welcome opinions from both engine and vdsm devels. Cheers, F. ----- Original Message ----- From: "Frantisek Kobzik" <fkobzik(a)redhat.com> To: vdsm-devel(a)lists.fedorahosted.org Sent: Monday, November 25, 2013 2:23:59 PM Subject: Re: [vdsm] Multiple graphics framebuffers - VDSM support Hi, it's been some time since the original mail, so I'm sending updated information. ----- Original Message ----- From: "Frantisek Kobzik" <fkobzik(a)redhat.com> To: vdsm-devel(a)lists.fedorahosted.org Sent: Thursday, November 7, 2013 11:47:46 AM Subject: [vdsm] Multiple graphics framebuffers - VDSM support Dear VDSM developers, I'm working on a patch that allows running a VM with multiple graphics framebuffers. This is handy when you want to run a VM with both SPICE and VNC. It's a 3.4 feature and it will certainly need a change in vdsm. Here is a list of changes in VDSM that are needed for this funcionality: a, Sending graphics/video (engine->vdsm) - currently we send two things: 1, "display" value (qxl/vnc [wat]) - vdsm uses this for determining if the graphics server is SPICE or VNC - this attribute is not really correct - it mixes up semantics of graphic framebuffer and videocard together. I believe this attribute should only contain information about the graphics ('spice', 'vnc' or 'spice,vnc' if you want both). if this the case, do you think we should rename the attribute to, let's say, 'graphics'? Is it even possible with regard to backward compatibility? or should I reuse 'display' attribute? 2, video device (json representation of the video card) - this is correct b, Reporting graphics ports (vdsm->engine) - currently we report 2 graphic ports ('displayPort' and 'secureDisplayPort') - if we want multiple framebuffers, we must report more ports (for VNC and SPICE together that would mean 3 ports (2 for spice, one for vnc). - there are two possible solutions for this: 1, ditch 'displayPort' and 'secureDisplayPort' and add new 'spicePort', 'spiceSecurePort', 'vncPort' fields or some kind of two level dict: { protocol -> secured/unsecured -> portNumber } 2, keep 'displayPort' and 'secureDisplayPort' and introduce new 'additionalDisplayPort' This would be friendlier to backward compatibility, but it's extremely ugly because of unclear semantics of the fields (in case of SPICE+VNC 'displayPort' and 'secureDisplayPort' would be related to SPICE, 'additionalDisplayPort' would be the VNC port. In case of VNC only, the 'displayPort' would be suddendly VNC port... ewww). I'd be very happy if you share your opinion about these changes. Cheers, Franta. _______________________________________________ vdsm-devel mailing list vdsm-devel(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

2 1

[Engine-devel] failed to add host into cluster
by Chen, Wei D 26 Nov '13

26 Nov '13

------=_NextPart_000_0063_01CE8F8D.53576440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Failed to add a node into cluster. I saw follow hints, but still don't know how to fix it. OS is fedora 19 both for node and engine, anyone can help me? Host *** does not comply with the cluster *** emulated machines. The Hosts emulated machines are clipper,none and the cluster is [rhel6.4.0, pc-1.0]} Best Regards, Dave Chen ------=_NextPart_000_0063_01CE8F8D.53576440 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIV/jCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIE6zCC A9OgAwIBAgIQUukCyhHoRJ2UZTgvoxowuzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTEzMDMxOTAwMDAwMFoX DTIwMDUzMDEwNDgzOFoweTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRQwEgYDVQQHEwtTYW50 YSBDbGFyYTEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVy bmFsIEJhc2ljIElzc3VpbmcgQ0EgNEEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDg sMyAndhJVfoD2wT6OMfdv4XddrzrPcssq7/pa+Mh29RvGejPaqe+X1QpAjewTXNRFDGt+C+0/Rs+ C3W4PAB8tzofl6qfKL7sWs+xMYJHiDAOarVaRNCA0M1dSBvvV73/qx+r5Z8IOmLxJxqCXIsJGnum H9XrRxuK0G+dkV6UoIMGHffZLoobdsB2c0YH++TzpvAOVjqiYOzr9Gx83DNBXCj8zeg+u7HrLrPI ihG6V+RUQ1szT/1GvNA6XIrhblWTgQSx9baOUJXhbzdAqpFxwAohTHDar8egdU9tsROusuYTpFFn /55aWQZaX6a3HjYc6A6ZfQFF1NGj28fvJ4GjAgMBAAGjggF3MIIBczAfBgNVHSMEGDAWgBStvZh6 NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUHmkqtNwo/kcYTiELP7ysES/wmPUwDgYDVR0PAQH/ BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwNgYDVR0lBC8wLQYIKwYBBQUHAwQGCisGAQQBgjcK AwQGCisGAQQBgjcKAwwGCSsGAQQBgjcVBTAXBgNVHSAEEDAOMAwGCiqGSIb4TQEFAWkwSQYDVR0f BEIwQDA+oDygOoY4aHR0cDovL2NybC50cnVzdC1wcm92aWRlci5jb20vQWRkVHJ1c3RFeHRlcm5h bENBUm9vdC5jcmwwOgYIKwYBBQUHAQEELjAsMCoGCCsGAQUFBzABhh5odHRwOi8vb2NzcC50cnVz dC1wcm92aWRlci5jb20wNQYDVR0eBC4wLKAqMAuBCWludGVsLmNvbTAboBkGCisGAQQBgjcUAgOg CwwJaW50ZWwuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQApws2j/ZKjUmeiLwbtblDoVI+rV+bIpbex IN/Vqa/IeSMSB3bmfswpEcYSZHHGjOI8qlyZt9dhT4nSDnrScKjmA8XvxZ3tmbNyYJybVQUV8jF/ DpADX1tGlMLxswxpJISXzLf0+DBr4cQ2ag9mwzrcN1nrOIOc+pxJtx9izyp3+bl3baulerkgZVS1 fotftH+FJLD/ex8BOcEuCIm2KVXJjs4YaZgoIBLYjTiK29JLVa15xdO305kPI1uXsu05sGuAwuFm Sklb6k5H1/eHlUbZLm4qQDtOH00L0ShJx3BAIAjD5RYptJDQiyPZQUvt8cq+apYpVMv3yxHO8jex 40LgMIIGZjCCBU6gAwIBAgIKFyvckgACAAAU0jANBgkqhkiG9w0BAQUFADB5MQswCQYDVQQGEwJV UzELMAkGA1UECBMCQ0ExFDASBgNVBAcTC1NhbnRhIENsYXJhMRowGAYDVQQKExFJbnRlbCBDb3Jw b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSA0QTAeFw0x MzA3MTgwMTEwMzdaFw0xNjA3MDIwMTEwMzdaMDsxFDASBgNVBAMTC0NoZW4sIFdlaSBEMSMwIQYJ KoZIhvcNAQkBFhR3ZWkuZC5jaGVuQGludGVsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAN50qdmWdvh7vbj60QYyg7t3euDjJ8OU7EkwSPOgX3DKIW1PgAjzkpXvCxMhIBPr/KWX 7OVqYgP/vY8X0gLYrtGgBjwIkPOmFrSB2oRNEQiAtbP8YyOlprYHDeAUHFziVb6UPjPD9sR15q00 rH41v9qhRcll5V2cz4krCAdzSEWMGxnpZMBS8vV3zrwD1fiU0LLyn8Nb1u1MT0Sh0ZKQrWC/Icv1 UWklTdaGkbUxUa3eUZZdH5ayXIfLir4h3hChmkWsjLeLWXMHz/fCn3KW6qP64+WJJr0kcnpOM/Sp 07F9F6yfdg27HVWEHAphROkHJFdHK47RxnWWrnmB6lLMdzkCAwEAAaOCAywwggMoMEQGCSqGSIb3 DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG 9w0DBzAdBgNVHQ4EFgQUUIOKK8gtAh2SucBYccty6S33jggwCwYDVR0PBAQDAgeAMB8GA1UdIwQY MBaAFB5pKrTcKP5HGE4hCz+8rBEv8Jj1MIHJBgNVHR8EgcEwgb4wgbuggbiggbWGVGh0dHA6Ly93 d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElz c3VpbmclMjBDQSUyMDRBLmNybIZdaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3Np dG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUyMENBJTIwNEEuY3Js MIH1BggrBgEFBQcBAQSB6DCB5TBsBggrBgEFBQcwAoZgaHR0cDovL3d3dy5pbnRlbC5jb20vcmVw b3NpdG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUy MENBJTIwNEEoMikuY3J0MHUGCCsGAQUFBzAChmlodHRwOi8vY2VydGlmaWNhdGVzLmludGVsLmNv bS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1 aW5nJTIwQ0ElMjA0QSgyKS5jcnQwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUIhsOMdYSZ5VGD /YEohY6fU4KRwAlngd69OZXwQwIBZAIBCDAfBgNVHSUEGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoD DDApBgkrBgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwwwRQYDVR0RBD4wPKAk BgorBgEEAYI3FAIDoBYMFHdlaS5kLmNoZW5AaW50ZWwuY29tgRR3ZWkuZC5jaGVuQGludGVsLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEAFKXJisQoKmP6JRz7poS0Z+AbM5QEpy/NTxT4lI+nHfznQcEW emgt5pFJORthxKKFipifuHQxDYpnmNBq5wkn5zLpnMJQVMqoG/FPP2NWXW7NHRmzewousUCjm6ci MSJbu7YNSfJAPz/fUznOKxmwBi5i+yROQXpeAx5eU9bcqaClBUt7e0FRyUCUEGfuwrzqamuPaxGc Jg0zS7t7uPLtMQ+Xg83nVUBmWzjCXEzJesEG4KkY9lXInQojn7nIqSYJyQnm+0xK1TKNQ/G/J2DD m2V7WDlfyECVbQwzwseJcFCET+zKvePggmgwoJ7Vjc/6gju3mj9wrr4TEil7PzVKIjCCBmcwggVP oAMCAQICChcsF54AAgAAFNMwDQYJKoZIhvcNAQEFBQAweTELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AkNBMRQwEgYDVQQHEwtTYW50YSBDbGFyYTEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24xKzAp BgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgNEEwHhcNMTMwNzE4MDExMDUy WhcNMTYwNzAyMDExMDUyWjA7MRQwEgYDVQQDEwtDaGVuLCBXZWkgRDEjMCEGCSqGSIb3DQEJARYU d2VpLmQuY2hlbkBpbnRlbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpHWFM hzvKyQ+h07xAyVymceQlT/Y1YK+nxXKFLq6Kglz8suv/Uk4ur+YXoBfW/+OWxjYU+misOO+apdAw my3KXs+222bBd7hmxvMdOuz5jN1m+dLYlMlWpWyvLe+3531ufG4yymmlGxfifVtqKVmWSZ8li1gm MbOGip1GU1dXfdckGwinmRFaSHFThcy+6jOKMY88cf7gRY/pJP6g3/tSwnO3LZgRZzqBu7VkZJpE phgfPHMgmNLWQRUuQ/PEO/XrLkCrNWo90RhQzYbvWMFOx+/y/VGRvf/QKqJBUj+cDOT7qLtp15lm vm5oBGC/qBLv5ty2ZSHU/lUih1Io4nclAgMBAAGjggMtMIIDKTBEBgkqhkiG9w0BCQ8ENzA1MA4G CCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0O BBYEFIQlFPFOAdRJpFVdkBxzADk9BtROMAsGA1UdDwQEAwIEMDAfBgNVHSMEGDAWgBQeaSq03Cj+ RxhOIQs/vKwRL/CY9TCByQYDVR0fBIHBMIG+MIG7oIG4oIG1hlRodHRwOi8vd3d3LmludGVsLmNv bS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0El MjA0QS5jcmyGXWh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0lu dGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDRBLmNybDCB9QYIKwYBBQUH AQEEgegwgeUwbAYIKwYBBQUHMAKGYGh0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2Vy dGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDRBKDIp LmNydDB1BggrBgEFBQcwAoZpaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9y eS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUyMENBJTIw NEEoMikuY3J0MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OCkcAJ Z4S52UGHhP9OAgFkAgENMB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMEMCkGCSsGAQQB gjcVCgQcMBowCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDBDBFBgNVHREEPjA8oCQGCisGAQQBgjcU AgOgFgwUd2VpLmQuY2hlbkBpbnRlbC5jb22BFHdlaS5kLmNoZW5AaW50ZWwuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQBKK79ulOFE5/S7yfejfIXz8xX3aRUmggULkjwh4sTe1M6JEKLDB9AqzNMKb/hy PHPDFAlSuYToRu5QUiIIREdC4+RJhZrJ/NRELZktPJrOIpydhKsOAODNle2Rlypq9XvmeCqElLiR XZTrBQQ4j4bMhnJVjS2h0ZULsR3qraV3ssWYjC1d6mBysmf4IdVnNSKECjGAJhLhwsow9igtjCzz qKZ9A62vrG+ag/vnlx8bOO7ReqoK/X3hCYvuappzZ7udulpjf5zD/oAv5xJU0S0mSr1XKyfNOCIT btX0zJM9tOoV1zr0eJb1I+aulgCjqqxaZqbvWdkQPdn++dAgQsmAMYIDvDCCA7gCAQEwgYcweTEL MAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRQwEgYDVQQHEwtTYW50YSBDbGFyYTEaMBgGA1UEChMR SW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3Vpbmcg Q0EgNEECChcr3JIAAgAAFNIwCQYFKw4DAhoFAKCCAgkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTMwODAyMDYzMzU5WjAjBgkqhkiG9w0BCQQxFgQUU0szBQqrHyk3 00cWkuAJkNAF1rQwcgYJKoZIhvcNAQkPMWUwYzALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoG CCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAIC MAsGCWCGSAFlAwQCATCBmAYJKwYBBAGCNxAEMYGKMIGHMHkxCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJDQTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMSsw KQYDVQQDEyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5nIENBIDRBAgoXLBeeAAIAABTTMIGa BgsqhkiG9w0BCRACCzGBiqCBhzB5MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFDASBgNVBAcT C1NhbnRhIENsYXJhMRowGAYDVQQKExFJbnRlbCBDb3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwg RXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSA0QQIKFywXngACAAAU0zANBgkqhkiG9w0BAQEFAASC AQBHOVJ8v26UwJh9yvZ9FQUcPFtV8uJx2HBXOaqoHDKtS3KWAOjFvfJxMdv/+gyLCvzjPUbp90DN 1GACK/Qye17dtXaxYxjkTZi2UwzoW9lYBqVvbYLY36gh6evmEQ9sKjHCFa1jKG/bi3bwibm+lgx3 KgeDmVRQCBsQQ8L8S9xR8QtBOGl0QLbdH9RKTEbIeKtt1DCaS93R9dNGj7mEQr+QtYZisxdjjBP7 +w4hCSQ5HfbgEouelZ7LvGGaSMWYROs9WDmlS8le5TK/v6gdfxL3W5Wtn8B+OZd4fntBR6OqzBLU 7ievh5r1t0WzgO5pbrUSFzPDTmcobVbgUCWcERfXAAAAAAAA ------=_NextPart_000_0063_01CE8F8D.53576440--

8 24

[Engine-devel] oVirt Updates - November 2013
by Itamar Heim 25 Nov '13

25 Nov '13

Case Studies - Dave Neary just published his interview with Martin Goldstone and Gary Lloyd, system administrators at the Keele university http://www.ovirt.org/Keele_University_case_study (we'd be happy to have more case studies, please contact Dave if you are willing to do one - its mostly just an interview with him) oVirt 3.3 - 3.3.1 with a slew of updates is finally out. http://www.ovirt.org/OVirt_3.3.1_release_notes - 3.3.2 beta planned once we GA 3.3.1. - sample scheduler plugins available here http://www.ovirt.org/External_Scheduler_Samples oVirt 3.4 - planning is on going, please join and help make oVirt better http://lists.ovirt.org/pipermail/users/2013-October/017451.html (clearly, only items with devel owners will make it) Conferences - Einav presented at an oVirt booth in LISA 2013 (Washington, DC) - Fosdem virt & IaaS devroom CFP[1] is open till December 1st http://bit.ly/1gMXdUH We also requested a stand/table/booth to demo oVirt (we'd love if oVirt users visiting Fosdem would volunteer to help man the stand/demo) - KVM Forum/CloudOpen sessions available http://www.ovirt.org/KVM_Forum_2013 Cross Distro - guest agent packages are now available for OpenSUSE 12.3, 13.1 and Factory, and SLES 11 SP3. (thanks Vinzenz for pushing and René for testing) - Ubuntu packages pushed by Zhou Zheng Sheng. - How To: Get oVirt 3.2 All-In-One working on Scientific Linux 6.4 (With fixes!) http://bit.ly/17BstPj Related - How to manage multiple nodes with oVirt (Japanese) http://lab.space-i.com/?p=1252 - oVirt node has a new plugin, allowing it to be used for The Foreman host discovery http://www.youtube.com/watch?v=V8TugleqF64 - how to use virt-sysprep with oVirt/RHEV http://bit.ly/1hy54Xx - script to easily move VMs by name from export domain https://github.com/ppiersonbt/ovfmaker - some oVirt and Dell Equalogic issues discussions http://dell.to/1gN3TlX http://bit.ly/1cXrIH2 - Intro to oVirt on Fedora (Spanish) http://www.itrestauracion.com.ar/?p=1505 - Christophe Fergeau published libgovirt 0.3.0 (storage domains, cd-rom and certificate handling improvements) http://red.ht/HVl4U2 - helper script by Humble to print list of VMs and their nic/mac/ip http://bit.ly/1ePpMjF - Want to play with oVirt Neutron and GRE Tunneling? http://www.ovirt.org/OVirt_Neutron_GRE_Integration_-_How_To - How To: Install rhev-agents on Scientific Linux 6x http://bit.ly/1cZRydo - How To: Convert a server running on VMware ESXi 5x to oVirt 3.2 http://bit.ly/17x2X1O

1 0

[Engine-devel] Java Newbie: Renaming some functions to fix findbugs warnings
by Adam Litke 22 Nov '13

22 Nov '13

Hello, I am working on resolving some warnings produced by findbugs and am looking for some advice on how to properly resolve the problem. The Frontend class has several pairs of methods where a capitalized version is a deprecated static form and the camelCase version is the instance method. For example: @Deprecated public static void RunQuery(...) - and - public void runQuery(...) In both cases the parameters are the same so simply renaming RunQuery to runQuery will result in a conflict. Since I am new to Java and the ovirt-engine project I am looking for some advice on how to fix the function name without breaking the code or people's sense of aesthetics. Since this is a deprecated function, would it be terrible to rename it to 'runQueryStatic' or 'runQueryDeprecated'? Since the language provides syntactic annotations for 'static' and 'deprecated', both of these names feel dirty but I am not sure what would be better. Thanks for helping out a newbie! --Adam

2 2

[Engine-devel] Fwd: Custom properties per device + vNIC profile = not working (< 3.3)
by Martin Perina 21 Nov '13

21 Nov '13

Hi Mike, ----- Original Message ----- > From: "Mike Kolesnik" <mkolesni(a)redhat.com> > To: "engine-devel" <engine-devel(a)ovirt.org> > Cc: "Barak Azulay" <bazulay(a)redhat.com>, "Martin Perina" <mperina(a)redhat.com>, "Livnat Peer" <lpeer(a)redhat.com>, > "Itamar Heim" <iheim(a)redhat.com> > Sent: Monday, November 11, 2013 8:49:33 AM > Subject: Custom properties per device + vNIC profile = not working (< 3.3) > > Hi, > > I came across a situation where I wanted to define custom properties on a > vNIC profile sitting under a network in a 3.2 data center. > From what I saw the configuration value for custom properties > (CustomDeviceProperties) is split into 4, one per each version (3.0, 3.1, > 3.2, 3.3). > Since vNIC profile is located under the DC tree, it takes the DC version - > 3.2 in this specific case. Custom Device Properties were designed to be specified for each cluster version independently, it doesn't care about DC version. AFAIK cluster version defines what features are available ... > > I tried to set the config value for 3.2 but got: > $ engine-config -s > CustomDeviceProperties="{type=interface;prop={myProp=[a-zA-Z0-9-]+}}" > --cver=3.2 > Cannot set value {type=interface;prop={myProp=[a-zA-Z0-9-]+}} to key > CustomDeviceProperties. Device custom properties are not supported in > version 3.2 > > This is already not very good, since in a 3.2 DC there can be 3.3 clusters > with 3.3 hosts that do support custom device properties. Specify your properties for 3.3 version, since they will be used in 3.3 clusters ... > > I also tried to alter the config value in the DB directly, but the custom > properties code ignored it since custom properties are not supported in 3.2. > So, de facto, I have no reasonable way as a user to define custom device > properties to use for my vNIC profiles in DC < 3.3. There are two configuration properties for Custom Device Properties: 1) SupportCustomDeviceProperties - defines in what version properties are supported - cannot be altered by users of course 2) CustomDeviceProperties - holds properties specification for each version - can be defined using engine-config > > I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=1028757 for > this, however I also want to discuss the situation: I looked at the bug and the problem is, that management network profile is bound to DC and not the Cluster. And that's something we never thought of ... > > 1. As a user, I can't set custom properties for level < 3.3 which is not > good. Well, it's 3.3 feature, so it looks OK for me > Removing the blocking, and loading custom properties for all versions would > fix the bug and allow using custom device properties for older versions, the > reasonable place to block this would be running a VM (or plugging a device). > Basically this is the lesser issue.. > > 2. I just don't see the added value of splitting the definition of the > properties per level.. The idea behind the version splitting was: 1) We have a device with a feature that doesn't work correctly with version 3.3, but it's fixed in 3.4 2) By specifying custom property per version we cane disable this feature for 3.3 and enable for 3.4 > The custom properties are extensions which might or might not be available to > a certain VM, I don't see how having different sets of custom properties per > version (what version, DC version, cluster version?) would make any > difference - either the VM can utilize the extension given some state of the > system, or it can't, but the determining factor is not the version but > rather the availability of the extension. > For example, I can have a hook for vNIC altering some property installed on > host A and not host B, if the VM runs on host A it will get this capability > and on host B it won't, regardless the DC version the VM is in. > > This is not to say we shouldn't block custom properties on the engine-VDSM > API level since it's only available since 3.3, but this is handled by > another config value (SupportCustomDeviceProperties) which is not alterable > by the user. > So basically, I think splitting the value per version is over complication > and see no added value to the users, just more maintenance should they > choose to use this feature. > > Your thoughts please. AFAIK only network and storage team wanted to use device custom properties in 3.3 version, but I'm not sure what's current usage status. But IMHO it's too late for 3.3 to change specification ... Martin

4 9

[Engine-devel] Problem building 3.3.1 branch
by Bob Doolittle 21 Nov '13

21 Nov '13

Hi, I'm trying to build engine for the first time and running into a build error. I'm a seasoned Unix developer, but new to some aspects of Linux development like git and maven, so I could be doing something naive. I'm following the instructions here: http://www.ovirt.org/OVirt_Engine_Development_Environment I did a clone of the engine repository, and did "git checkout -b myengine origin/ovirt-engine-3.3.1" to create my own branch based on 3.3.1 (current - I realize it's not quite done). Then, when I did "make install-dev PREFIX=$HOME/ovirt-engine" it failed when building the "Engine Web Root", specifically in the FileServletTest. Relevant build log is here: http://pastebin.com/JRcyWvtr Can anyone suggest what I've done wrong, or whether there's a problem with the repository at the moment? I'd appreciate any guidance. Thanks, Bob

4 9

[Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class
by Shubhendu Tripathi 21 Nov '13

21 Nov '13

This is a multi-part message in MIME format. --------------020507040501040703080208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, In the case of Gluster, as there are no one to one mappings available for all the error messages from Gluster, we set the error in the VdcFault object as NULL. We also populate the actual error from the Gluster as error message in the fault object. /getReturnValue().getExecuteFailedMessages().add(error);// //getReturnValue().getFault().setMessage(error);// //getReturnValue().getFault().setError(null);/ Because of above settings and the below code snippet in /Frontend.java/ class the error message as is gets displayed on the error dialog - / //public String translateVdcFault(final VdcFault fault) {// // return getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() == null// // ? fault.getMessage() : fault.getError().toString());// //}// / Well and good till now !! But while translation of the error messages, all the occurrences of "." get replaced with "_". This causes an issue for the gluster errors. If the error message sent from gluster has "."s (say IP Address of a host or FQDN for a host), that also gets replaced with "_" and the error message does not look correct. Request your suggestion for handling such a case. *PS: *One thing I can think of is, introducing a flag called /isExternalError/ in /VdcFault/ class to identify if the source of the fault is external. From Gluster we would set the flag as /true/, and while replacement of "." with "_", if the flag is set it will not do the replacements. Regards, Shubhendu --------------020507040501040703080208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi,<br> <br> In the case of Gluster, as there are no one to one mappings available for all the error messages from Gluster, we set the error in the VdcFault object as NULL.<br> We also populate the actual error from the Gluster as error message in the fault object.<br> <br> <font color="#000099"><i>getReturnValue().getExecuteFailedMessages().add(error);</i><i><br> </i><i>getReturnValue().getFault().setMessage(error);</i><i><br> </i><i>getReturnValue().getFault().setError(null);</i></font><br> <br> Because of above settings and the below code snippet in <i>Frontend.java</i> class the error message as is gets displayed on the error dialog -<br> <font color="#000099"><i><br> </i><i>public String translateVdcFault(final VdcFault fault) {</i><i><br> </i><i>        return getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() == null</i><i><br> </i><i>                ? fault.getMessage() : fault.getError().toString());</i><i><br> </i><i>}</i><i><br> </i></font><br> Well and good till now !!<br> <br> But while translation of the error messages, all the occurrences of "." get replaced with "_".<br> This causes an issue for the gluster errors. If the error message sent from gluster has "."s (say IP Address of a host or FQDN for a host), that also gets replaced with "_" and the error message does not look correct.<br> <br> Request your suggestion for handling such a case.<br> <br> <b>PS: </b>One thing I can think of is, introducing a flag called <i>isExternalError</i> in <i>VdcFault</i> class to identify if the source of the fault is external. From Gluster we would set the flag as <i>true</i>, and while replacement of "." with "_", if the flag is set it will not do the replacements.<br> <br> Regards,<br> Shubhendu <br> </body> </html> --------------020507040501040703080208--

4 11

[Engine-devel] Things to be done to support Ubuntu hosts
by Zhou Zheng Sheng 20 Nov '13

20 Nov '13

Hi, Recently Ubuntu support is added to VDSM, and .deb binray packages can be downloaded from launchpad.net PPA [1]. Most of the key features such as storage management and VM lifecycle work on Ubuntu. The cross distribution network management patches are upstream as well. One big piece left is making ovirt-host-deploy support Ubuntu, so that we can manage Ubuntu hosts from Engine, thus close the gap on host side. In May 2013 I made some hacks to ovirt-host-deploy and otopi. I made it skipped parts not supported on Ubuntu and configure the environment manually, and successfully added Ubuntu host to Engine [2]. Unfortunately I have no plans to continue on it, but I'd like to make a summary of the things I hacked to help anyone who wants to submit patches in future. I was to add a WIKI page but I found there were not many items, so a mail would be enough. 1. Package management operations Both otopi and ovirt-host-deploy query for dependency packages and install them on demand. The otopi package management just supports yum, we need to add apt-get support. Package names are different in Ubuntu, so I made a list mapping the names. The list in in VDSM source directory, debian/dependencyMap.txt . 2. Network configuration operations ovirt-host-deploy asks VDSM's configNetwork.py to create bridge network. Cross distribution support patches for configNetwork.py are under review. ovirt-host-deploy supports Ubuntu bridge configuration as long as they are merged. [1] https://launchpad.net/~zhshzhou/+archive/vdsm-ubuntu [2] http://www.ovirt.org/images/5/57/Shanghai-VDSM-on-Ubuntu.pdf Here goes the detailed hack patch. The hack was base on v1.0.1, I rebased it to the latest master. The rebased patch are not tested. If you find this email useless, it's actually a good news, which means there is not a lot of work and problems ahead ;-) Hack patch for ovirt-host-deploy. >From 120493a242046d19794ef3da83b32486d372aa39 Mon Sep 17 00:00:00 2001 From: Zhou Zheng Sheng <zhshzhou(a)linux.vnet.ibm.com> Date: Wed, 13 Nov 2013 18:02:26 +0800 Subject: [PATCH] Ubuntu Hacks Change-Id: Ifb4ebc829101c92d06475619b1b5986e87b83d57 Signed-off-by: Zhou Zheng Sheng <zhshzhou(a)linux.vnet.ibm.com> --- src/plugins/ovirt-host-deploy/gluster/packages.py | 17 +++++---- src/plugins/ovirt-host-deploy/tune/tuned.py | 3 +- src/plugins/ovirt-host-deploy/vdsm/bridge.py | 45 ++++++++++++----------- src/plugins/ovirt-host-deploy/vdsm/packages.py | 9 +++-- src/plugins/ovirt-host-deploy/vdsm/pki.py | 3 +- src/plugins/ovirt-host-deploy/vdsm/software.py | 2 + src/plugins/ovirt-host-deploy/vdsm/vdsmid.py | 3 +- 7 files changed, 45 insertions(+), 37 deletions(-) diff --git a/src/plugins/ovirt-host-deploy/gluster/packages.py b/src/plugins/ovirt-host-deploy/gluster/packages.py index 1fecfda..eb37744 100644 --- a/src/plugins/ovirt-host-deploy/gluster/packages.py +++ b/src/plugins/ovirt-host-deploy/gluster/packages.py @@ -60,13 +60,13 @@ class Plugin(plugin.PluginBase): ), ) def _validation(self): - if not self.packager.queryPackages(patterns=('vdsm-gluster',)): - raise RuntimeError( - _( - 'Cannot locate gluster packages, ' - 'possible cause is incorrect channels' - ) - ) + # if not self.packager.queryPackages(patterns=('vdsm-gluster',)): + # raise RuntimeError( + # _( + # 'Cannot locate gluster packages, ' + # 'possible cause is incorrect channels' + # ) + # ) self._enabled = True @plugin.event( @@ -74,7 +74,8 @@ class Plugin(plugin.PluginBase): condition=lambda self: self._enabled, ) def _packages(self): - self.packager.installUpdate(('vdsm-gluster',)) + # self.packager.installUpdate(('vdsm-gluster',)) + pass @plugin.event( stage=plugin.Stages.STAGE_CLOSEUP, diff --git a/src/plugins/ovirt-host-deploy/tune/tuned.py b/src/plugins/ovirt-host-deploy/tune/tuned.py index d8e00c5..d0dcea5 100644 --- a/src/plugins/ovirt-host-deploy/tune/tuned.py +++ b/src/plugins/ovirt-host-deploy/tune/tuned.py @@ -70,7 +70,8 @@ class Plugin(plugin.PluginBase): condition=lambda self: self._enabled, ) def _packages(self): - self.packager.installUpdate(('tuned',)) + # self.packager.installUpdate(('tuned',)) + pass @plugin.event( stage=plugin.Stages.STAGE_MISC, diff --git a/src/plugins/ovirt-host-deploy/vdsm/bridge.py b/src/plugins/ovirt-host-deploy/vdsm/bridge.py index 3789d62..64cce40 100644 --- a/src/plugins/ovirt-host-deploy/vdsm/bridge.py +++ b/src/plugins/ovirt-host-deploy/vdsm/bridge.py @@ -595,7 +595,8 @@ class Plugin(plugin.PluginBase): stage=plugin.Stages.STAGE_INTERNAL_PACKAGES, ) def _internal_packages(self): - self.packager.install(packages=('iproute',)) + # self.packager.install(packages=('iproute',)) + pass @plugin.event( stage=plugin.Stages.STAGE_VALIDATION, @@ -771,27 +772,27 @@ class Plugin(plugin.PluginBase): interface = self._getInterfaceToInstallBasedOnDestination( address=self.environment[odeploycons.VdsmEnv.ENGINE_ADDRESS] ) - parameters = self._rhel_getInterfaceConfigParameters(name=interface) - - # The followin can be executed - # only at node as we won't reach here - # if we are not running on node - if ( - self.environment[odeploycons.VdsmEnv.OVIRT_NODE] and - self._interfaceIsBridge(name=interface) - ): - nic = interface.replace('br', '', 1) - self._removeBridge( - name=interface, - interface=nic, - ) - interface = nic - - self._createBridge( - name=self.environment[odeploycons.VdsmEnv.MANAGEMENT_BRIDGE_NAME], - interface=interface, - parameters=parameters, - ) + # parameters = self._rhel_getInterfaceConfigParameters(name=interface) + + # # The followin can be executed + # # only at node as we won't reach here + # # if we are not running on node + # if ( + # self.environment[odeploycons.VdsmEnv.OVIRT_NODE] and + # self._interfaceIsBridge(name=interface) + # ): + # nic = interface.replace('br', '', 1) + # self._removeBridge( + # name=interface, + # interface=nic, + # ) + # interface = nic + + # self._createBridge( + # name=self.environment[odeploycons.VdsmEnv.MANAGEMENT_BRIDGE_NAME], + # interface=interface, + # parameters=parameters, + # ) self._waitForRoute( host=( diff --git a/src/plugins/ovirt-host-deploy/vdsm/packages.py b/src/plugins/ovirt-host-deploy/vdsm/packages.py index d819caa..b526d4b 100644 --- a/src/plugins/ovirt-host-deploy/vdsm/packages.py +++ b/src/plugins/ovirt-host-deploy/vdsm/packages.py @@ -68,7 +68,8 @@ class Plugin(plugin.PluginBase): stage=plugin.Stages.STAGE_VALIDATION, ) def _validation(self): - result = self.packager.queryPackages(patterns=('vdsm',)) + # result = self.packager.queryPackages(patterns=('vdsm',)) + result = ({'version': '4.10.3', 'release': '1'},) if not result: raise RuntimeError( _( @@ -106,8 +107,8 @@ class Plugin(plugin.PluginBase): self.services.state('vdsmd', False) if self.services.exists('supervdsmd'): self.services.state('supervdsmd', False) - self.packager.install(('qemu-kvm-tools',)) - self.packager.installUpdate(('vdsm', 'vdsm-cli')) + # self.packager.install(('qemu-kvm-tools',)) + # self.packager.installUpdate(('vdsm', 'vdsm-cli')) @plugin.event( stage=plugin.Stages.STAGE_CLOSEUP, @@ -119,7 +120,7 @@ class Plugin(plugin.PluginBase): self.services.state('libvirt-guests', False) self.services.startup('libvirt-guests', False) - self.services.startup('vdsmd', True) + # self.services.startup('vdsmd', True) if not self.services.supportsDependency: if self.services.exists('libvirtd'): self.services.startup('libvirtd', True) diff --git a/src/plugins/ovirt-host-deploy/vdsm/pki.py b/src/plugins/ovirt-host-deploy/vdsm/pki.py index f374a99..c013527 100644 --- a/src/plugins/ovirt-host-deploy/vdsm/pki.py +++ b/src/plugins/ovirt-host-deploy/vdsm/pki.py @@ -208,7 +208,8 @@ class Plugin(plugin.PluginBase): condition=lambda self: self._enabled, ) def _packages(self): - self.packager.install(('m2crypto',)) + # self.packager.install(('m2crypto',)) + pass @plugin.event( stage=plugin.Stages.STAGE_MISC, diff --git a/src/plugins/ovirt-host-deploy/vdsm/software.py b/src/plugins/ovirt-host-deploy/vdsm/software.py index 2f0ec80..a226816 100644 --- a/src/plugins/ovirt-host-deploy/vdsm/software.py +++ b/src/plugins/ovirt-host-deploy/vdsm/software.py @@ -65,6 +65,8 @@ class Plugin(plugin.PluginBase): version=ver, ) ) + elif dist == 'Ubuntu': + pass else: raise RuntimeError( _('Distribution {distribution} is not supported').format( diff --git a/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py b/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py index 328ad17..465212a 100644 --- a/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py +++ b/src/plugins/ovirt-host-deploy/vdsm/vdsmid.py @@ -78,7 +78,8 @@ class Plugin(plugin.PluginBase): ) def _packages(self): if platform.machine() in ('x86_64', 'i686'): - self.packager.install(('dmidecode',)) + # self.packager.install(('dmidecode',)) + pass @plugin.event( stage=plugin.Stages.STAGE_CUSTOMIZATION, -- 1.7.11.7 Hack patch for otopi. >From 3e7022b740f24d8053d3e32c20fa6d492631db80 Mon Sep 17 00:00:00 2001 From: Zhou Zheng Sheng <zhshzhou(a)linux.vnet.ibm.com> Date: Wed, 13 Nov 2013 17:55:39 +0800 Subject: [PATCH] Ubuntu Hacks --- src/plugins/otopi/network/hostname.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/plugins/otopi/network/hostname.py b/src/plugins/otopi/network/hostname.py index bb07627..28b4866 100644 --- a/src/plugins/otopi/network/hostname.py +++ b/src/plugins/otopi/network/hostname.py @@ -63,7 +63,8 @@ class Plugin(plugin.PluginBase): stage=plugin.Stages.STAGE_INTERNAL_PACKAGES, ) def _internal_packages(self): - self.packager.install(packages=['iproute']) + # self.packager.install(packages=['iproute']) + pass @plugin.event( stage=plugin.Stages.STAGE_VALIDATION, -- 1.7.11.7 -- Thanks and best regards! Zhou Zheng Sheng / 周征晟 E-mail: zhshzhou(a)linux.vnet.ibm.com Telephone: 86-10-82454397

5 10

[Engine-devel] Question about Engine user session timeout
by Vojtech Szocs 19 Nov '13

19 Nov '13

Hi guys, I see two different config values for dealing with Engine user session timeout. First, from packaging/etc/engine-config/engine-config.properties file: - UserSessionTimeOutInterval.description=Session timeout interval in minutes, after which it will be expired and clean. A negative value indicates the session should never timeout. - UserSessionTimeOutInvalidationInterval.description=Session timeout invalidation interval in minutes. Specifies the interval in which the invalidation check should occur. Then, in org.ovirt.engine.core.common.config.ConfigValues enum: - UserSessionTimeOutInterval (default 30) - UserSessionTimeOutInvalidationInterval (default 30) Looking at Backend#Initialize, both of these values are used when scheduling "cleanExpiredUsersSessions" job: - UserSessionTimeOutInterval = initialDelay param, i.e. the initial delay before the first activation [SchedulerUtil#scheduleAFixedDelayJob] - UserSessionTimeOutInvalidationInterval = taskDelay param, i.e. the delay between jobs [SchedulerUtil#scheduleAFixedDelayJob] So if I read this correctly, if UserSessionTimeOutInterval=100 then UserSessionTimeOutInvalidationInterval is relevant only after first 100min of Engine uptime. Why do we have two different config values for Engine user session timeout? i.e. why don't we use same value for both initialDelay & taskDelay param? Thanks, Vojtech

3 6

[Engine-devel] When is ovirt-engine expected to start supporting wildfly?
by Mooli Tayer 19 Nov '13

19 Nov '13

Thanks, Mooli Tayer.

4 4

[Engine-devel] [UX] how to design a bar/line chart?
by Tomas Jelinek 18 Nov '13

18 Nov '13

Hi all, There is a feature request [1] which aims to replace the resource utilization graphs (for example the cpu utilization from vm tab) by some which shows not only the actual percentage which is not so useful by some monitor graph. I have the following concerns: - I can think of a bar chart or a line chart and not sure what would be better. - Not sure if replacing the current chart with a bar/line chart would make the statistics readable enough. Maybe if you hover the chart it could pop up a bigger version of the chart? Or not needed? - Would it be enough to have it in one color? Or should it be something like "the bigger the utilization the more red"? Please advise from the UX perspective. As soon as the final design will be a bit more clear I will provide a feature page. Thank you, Tomas [1]: https://bugzilla.redhat.com/show_bug.cgi?id=803251

11 51

[Engine-devel] Using REST API in web UI - design proposal review call
by Vojtech Szocs 18 Nov '13

18 Nov '13

Hi everyone, we're moving towards using REST API in web UI (i.e. WebAdmin and UserPortal) and would like to hear your opinion on the matter. The initial meeting (conference call) is scheduled on Wednesday, November 20 at 14:30 CET / 15:30 TLV / 08:30 Boston timezone. I'll send the meeting invite with details in a separate email. Everyone is welcome to join and share his (her) thoughts. Regards, Vojtech PS: don't be scared to join just because there's "web UI" in meeting name! This is mostly about the general concept and design of oVirt SDK for JavaScript.

2 2