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

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

18 Nov '13

------=_Part_26065156_1804954053.1384790432845 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit The following is a new meeting request: Subject: REST API in web UI - design proposal review call Organizer: "Vojtech Szocs" <vszocs(a)redhat.com> Time: Wednesday, November 20, 2013, 2:30:00 PM - 4:30:00 PM GMT +01:00 Belgrade, Bratislava, Budapest, Ljubljana, Prague Required: Optional: engine-devel(a)ovirt.org *~*~*~*~*~*~*~*~*~* Hi guys, 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. This is a review call to summarize and discuss "Using REST API In Web UI" feature design proposal: http://www.ovirt.org/Features/Design/Using_REST_API_In_Web_UI Meeting agenda: - review current state, i.e. using GWT RPC - review main aspects of design proposal - discussion / feel free to ask questions anytime during the meeting Estimated duration: ~2 hrs. To join this meeting, dial into the Intercall bridge and use following conference code: 712 886 7405 # [https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405] Everyone is welcome to join and share his (her) thoughts. Regards, Vojtech ------=_Part_26065156_1804954053.1384790432845 Content-Type: text/calendar; charset=utf-8; method=REQUEST; name=meeting.ics Content-Transfer-Encoding: 7bit BEGIN:VCALENDAR PRODID:Zimbra-Calendar-Provider VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Europe/Belgrade BEGIN:STANDARD DTSTART:16010101T030000 TZOFFSETTO:+0100 TZOFFSETFROM:+0200 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU TZNAME:CET END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETTO:+0200 TZOFFSETFROM:+0100 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1SU TZNAME:CEST END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:8ec06680-c452-4cd9-a6fe-b94dd32a813d SUMMARY:REST API in web UI - design proposal review call ATTENDEE;CN=engine-devel;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRU E:mailto:engine-devel@ovirt.org ORGANIZER;CN=Vojtech Szocs:mailto:vszocs@redhat.com DTSTART;TZID="Europe/Belgrade":20131120T143000 DTEND;TZID="Europe/Belgrade":20131120T163000 STATUS:CONFIRMED CLASS:PUBLIC X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY TRANSP:OPAQUE LAST-MODIFIED:20131118T160032Z DTSTAMP:20131118T160032Z SEQUENCE:0 DESCRIPTION:The following is a new meeting request:\n\nSubject: REST API in web UI - design proposal review call \nOrganizer: "Vojtech Szocs" <vszocs@re dhat.com> \n\nTime: Wednesday\, November 20\, 2013\, 2:30:00 PM - 4:30:00 PM GMT +01:00 Belgrade\, Bratislava\, Budapest\, Ljubljana\, Prague\n \nRequir ed: \nOptional: engine-devel(a)ovirt.org \n\n*~*~*~*~*~*~*~*~*~*\n\nHi guys\, \n\nwe're moving towards using REST API in web UI (i.e. WebAdmin and UserPor tal) and would like to hear your opinion on the matter.\n\nThis is a review call to summarize and discuss "Using REST API In Web UI" feature design prop osal: http://www.ovirt.org/Features/Design/Using_REST_API_In_Web_UI\n\nMeeti ng agenda:\n- review current state\, i.e. using GWT RPC\n- review main aspec ts of design proposal\n- discussion / feel free to ask questions anytime dur ing the meeting\n\nEstimated duration: ~2 hrs.\n\nTo join this meeting\, dia l into the Intercall bridge and use following conference code: 712 886 7405 # [https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867 405]\n\nEveryone is welcome to join and share his (her) thoughts.\n\nRegards \,\nVojtech\n BEGIN:VALARM ACTION:DISPLAY TRIGGER;RELATED=START:-PT5M DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR ------=_Part_26065156_1804954053.1384790432845--

1 0

[Engine-devel] move api from /api to /ovirt-engine/api
by Michael Pasternak 18 Nov '13

18 Nov '13

Hey Alon, i've noticed that ForwardServlet does not address URI parameters (such as query/matrix), i.e all destinations of this servlet will lack URI parameters been passed at source. On 11/06/2013 12:10 PM, Alon Bar-Lev wrote: > Alon Bar-Lev has posted comments on this change. > > -- > To view, visit http://gerrit.ovirt.org/20786 > To unsubscribe, visit http://gerrit.ovirt.org/settings> > -- Michael Pasternak RedHat, ENG-Virtualization R&D

2 4

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

18 Nov '13

Hi, we're going to branch and build oVirt 3.3.2 beta on Nov 27th. A bug tracker is available at [1] and it shows only 2 bugs blocking the release: Bug 1029792 - VDSM does not report the qemu version in capabilities, if qemu-kvm-rhev is used Bug 1029885 - cloud-init testcase does not work in engine 3.3.1 The following is a list of the bugs still open with target 3.3.2 or 3.3: Whiteboard Bug ID Summary 991267 [RFE] Add TUI information to log file. infra 987982 When adding a host through the REST API, the error message says that "rootPassword" is required, but ... infra 1017267 Plaintext user passwords in async_tasks database infra 1020344 Power Managent with cisco_ucs problem infra 1009899 exportDbSchema scripts generates output file with wrong name infra 1029792 VDSM does not report the qemu version in capabilities, if qemu-kvm-rhev is used integration 1026933 pre-populate ISO domain with virtio-win ISO integration 1026930 Package virtio-win and put it in ovirt repositories integration 1030437 RFE: Configuration of email notifications 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 network 988002 [oVirt] [network] Add button shouldn't appear on specific network network 987916 [oVirt] [provider] Dialog doesn't update unless focus lost network 987999 [oVirt] [provider] Add button shouldn't appear on specific provider 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 1016118 async between masterVersion : can't connect to StoragePool storage 987917 [oVirt] [glance] API version not specified in provider dialog storage 1029069 Live storage migration snapshot removal fails, probably due to unexpected qemu-img output 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 set the target to 3.3.2 and add the bug to the tracker if you think that 3.3.2 should not be released without it fixed. Please also update the target to 3.3.3 or any next release for bugs that won't be in 3.3.2: it will ease gathering the blocking bugs for next releases. 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]. [1] https://bugzilla.redhat.com/1027349 [2] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1

Re: [Engine-devel] RSDL breakage in oVirt upstream
by Michael Pasternak 15 Nov '13

15 Nov '13

Hi Shubhendu, On 11/14/2013 04:32 PM, Shubhendu Tripathi wrote: > Hi Michael/Ori, > > There is payload breakage for RSDL in upstream oVirt. can you elaborate a bit? [1] works for me. [1] http://localhost:8080/api?rsdl > This has happened somewhere between the patches gerrit.ovirt.org/#/c/20610/ and http://gerrit.ovirt.org/#/c/15409/. > If I try to test out with patch http://gerrit.ovirt.org/#/c/15409/, it does break. > > Not sure what could be the issue. Tried debugging but not able to figure it out. > > Kindly help me on the same figuring out what could be the issue. > > Thanks and Regards, > Shubhendu > -- Michael Pasternak RedHat, ENG-Virtualization R&D

2 2

[Engine-devel] [QE] ovirt-engine 3.3.1-2 published in beta repository
by Sandro Bonazzola 15 Nov '13

15 Nov '13

Hi, ovirt-engine 3.3.1-2 has been published in beta repository and is ready for testing. Bugs fixed in this version: {{BZ|1023739}} - Cannot create same Local SD path on different Hosts {{BZ|1009391}} - Change multi-monitor setting in VM Console option dialog for 3.2 compatible cluster {{BZ|1025313}} - support relative answer file name<br> {{BZ|1028748}} - answer files are world-readable and contain passwords Other fixes: Fixed a bug which caused failure to run VM with VNC console -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 2

[Engine-devel] ovirt-cli 3.3.0.1 released
by Michael Pasternak 14 Nov '13

14 Nov '13

- at vm.start() --vm-os-boot doesn't send the order of devices #921464 - rephrase status command help - add option to retrieve system summary #854369 - accept IP address as FQ argument rather than string #886067 - fix broken pipe - Bad error message when trying to create a new Role #908284 - add flag --dont-validate-cert-chain #915231 - collection-based-options could be passed in 2 ways #859684 - make NO_SUCH_ACTION error a bit more clear - ovirt-cli DistributionNotFound exception on f18 #881011 - ovirt-shell misleading help for command "connect" #907943 - show event -id accept strings instead of numeric values #886786 - Use vncviewer passwordFile instead of passwdInput More details can be found at [1]. [1] http://wiki.ovirt.org/Cli-changelog -- Michael Pasternak RedHat, ENG-Virtualization R&D

1 5

[Engine-devel] Error message while trying to delete default cluster
by Shubhendu Tripathi 14 Nov '13

14 Nov '13

Hi, While trying to delete the Default cluster in oVirt it shows the below error message - "Cannot remove default Host Cluster. Cannot remove Cluster. One or more Template(s) are still associated with it" But in the case of RHSC, Templates are not used and this message is not relevant. [1]. Can we opt for not installing the templates while engine setup? And would it be having any impact/consequences ? Kindly provide your thoughts and possibility of the same. Thanks and Regards, Shubhendu PS: [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1019838

2 1

[Engine-devel] Consideration of the permission type
by Piotr Kliczewski 14 Nov '13

14 Nov '13

Hello everyone, I am working on https://bugzilla.redhat.com/show_bug.cgi?id=878812 bug so I played a bit with the code to understand how permission system works and noticed few things (please correct me if I am wrong): - In order to login to admin portal user need to have one of the admin roles (role_type = 1) - system tree is built using number of queries - before running each query permission validation happens so the code checks whether the user is able to run a query - I noticed that none of the queries required to build system tree is admin query and validation depends on result of getUser().isAdmin() (Please check http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manager/… line 123). This statement is always true for a user which was able to log in to admin portal. I was able to come up with following ways to solve this issue (please help to find the good enough): - fix verification - filter results of query - change a bit permission model. The structure is quite flat (there are only 2 role_types) or we could go with containers as it was proposed in bug description. Thanks, Piotr

1 0

[Engine-devel] OpenLdap and Kerberos for oVirt on f19
by Piotr Kliczewski 14 Nov '13

14 Nov '13

Hello everyone, I working on configuring OpenLdap 2.4.36 with kerberos for oVirt running on f19. I follow following instruction: https://bugzilla.redhat.com/show_bug.cgi?id=967327#c5 Please note that the instruction was written for f18. In order to have step 18 working from command line I had to set SASL_NOCANON to off. The reason was that I got: ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context When SASL_NOCANON is off I can search the ldap but have the same issue from java code: I got javax.naming.AuthenticationException: [LDAP: error code 49 - SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context]. Have this when connecting using engine-manage-domains (http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manager/… line 84). Can you please point me where is my config issue? I copied engine-devel for reference. Thanks, Piotr

2 3

[Engine-devel] daily oVirt 3.3.1 blocker status
by Sandro Bonazzola 14 Nov '13

14 Nov '13

Hi, The following blockers are still not fixed: VDSM: Bug 1022961 - Running a VM from a gluster domain uses mount instead of gluster URI Bug 1022975 - [vdsm] storage domain upgrade fails with attributeError Federico, Eduardo, can you provide an ETA for those? The following patches are targeted 3.3 and needs to be reviewed: http://gerrit.ovirt.org/#/q/branch:%255Eovirt*-3.3.*,n,z vdsm: support VIR_MIGRATE_ABORT_ON_ERROR Peter V. Saveliev vdsm ovirt-3.3 Oct 27 hsm: fix isoprefix KeyError for inactive domains Federico Simoncelli vdsm ovirt-3.3 Oct 20 +1 Read pool metadata once in StoragePool.getInfo() Federico Simoncelli vdsm ovirt-3.3 Oct 15 Make hsm.getVolumesList() pool independent. Federico Simoncelli vdsm ovirt-3.3 Oct 15 Adding [start|stop]MonitoringDomain(). Federico Simoncelli vdsm ovirt-3.3 Oct 15 stats: return domain lockspace status Federico Simoncelli vdsm ovirt-3.3 Oct 15 Make getRepoStats() a hsm method. Federico Simoncelli vdsm ovirt-3.3 Oct 15 Fix getStorageDomainInfo() logic. Federico Simoncelli vdsm ovirt-3.3 Oct 15 vm: add the transient disk support Federico Simoncelli vdsm ovirt-3.3 Oct 15 please review them and merge ASAP the patches meant to be in 3.3.1. I'm not aware of other blockers. If you're aware of any other blocker, please add it to the tracker bug (Bug 1019391 - Tracker: oVirt 3.3.1 release) -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

3 9

[Engine-devel] [QE] bug scrubing / triaging
by Sandro Bonazzola 13 Nov '13

13 Nov '13

Hi, Looking at bugzilla, there are 366 bugs without a target release. Some of them are in POST state but I'm pretty sure they should be in ON_QA or CLOSED state. A lot of them haven't a whiteboard set. Please review the bug list and help to scrub and triage them: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&… Thanks -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 1

[Engine-devel] Migrating an existing installation to hosted engine
by Yedidyah Bar David 13 Nov '13

13 Nov '13

Hi all, A message with the same subject was sent to arch around a month ago, see [1]. In short, it suggested two approaches: 1. Use p2v (or v2v) 2. Clean install of OS/engine software and use backup/restore. Following that, I pushed a few changes for engine-backup and engine-setup, with the intention of doing, briefly: 1. hosted-engine --deploy on new host 2. Install OS/software on new vm 3. backup on old engine machine 4. On new vm, do restore, which only restores the database and files, followed by engine-setup, which will fix whatever else needs to be fixed. Some of the changes are still pending, and are under some controversy. See [2], [3], [4]. A more detailed description of the suggested migration path is in [5]. What do you think? Should engine-setup do as little as possible to the system, or as much as needed to save the admin from any manual work? Should engine-setup doing an upgrade do the same as a new setup, or just whatever that's needed to adapt the config/database to the new code? A specific example: if admin chose during initial setup to automatically configure the firewall (iptables/firewalld), should upgrade update it again, or not touch it? Should engine-backup do all these things when doing a restore? Should we have some other utility to do these things? Should we merely document them and let the admin do this manually? [1] http://lists.ovirt.org/pipermail/arch/2013-October/001677.html [2] https://bugzilla.redhat.com/1024707 [3] http://gerrit.ovirt.org/20736 [4] http://gerrit.ovirt.org/20737 [5] http://www.ovirt.org/Migrate_to_Hosted_Engine -- Didi

2 1

[Engine-devel] UI Refresh synchronization
by Alexander Wels 12 Nov '13

12 Nov '13

Hi guys, I am working on providing our users with a better experience in regards to refresh synchronization. Quite often it will happen that you as a user will do a particular action, and it takes a whole refresh cycle for you to see the UI updated in response to that action. For instance if you remove a VM in the webadmin and click the ok button in the UI, the grid will still show the VM until the next refresh cycle, not when the VM is actually removed. I have created a wiki page that outlines the issues, and the ways we are intending to solve these issues [1]. Feel free to comment/e-mail/etc to let me know what you guys think. Alexander [1] http://www.ovirt.org/Features/Design/UIRefreshSynchronization

1 0

[Engine-devel] GWT DevMode plugin stopped working in Firefox 24+
by Greg Sheremeta 12 Nov '13

12 Nov '13

I submitted a bug. Please star it if this affects you. https://code.google.com/p/google-web-toolkit/issues/detail?id=8423 Detailed description (please be as specific as possible): The DevMode plugin does not work (Development Mode requires the GWT Developer Plugin). I encountered this in Firefox 24. Upgraded to Firefox 25 and plugin 1.25, still doesn't work. Workaround if you have one: roll back to Firefox 23. Greg Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gshereme(a)redhat.com

2 2

[Engine-devel] Permissions involved in using REST API
by Jonathan Daugherty 11 Nov '13

11 Nov '13

Hi all, I'm interested in setting up a non-administrative user account to be used to access the oVirt REST API. I have a user who is testing this functionality by integrating some Vagrant-related software to talk to oVirt. The user's oVirt account is a non-admin account with enough privileges to create and modify VMs on one of my clusters. What we found is that the account is unable to make requests to, say, /api/vms (he gets 401 or 404 responses) and instead gets a response indicating that the account has "insufficient permissions." My engine.log says of the access only this: 2013-11-06 14:50:28,158 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (ajp--127.0.0.1-8702-13) Operation Failed: query execution faile d due to insufficient permissions. and in server.log I have see Java tracebacks involving this[1]: 2013-11-06 14:50:28,159 WARN [org.jboss.resteasy.core.SynchronousDispatcher] (ajp--127.0.0.1-8702-13) failed to execute: org.ovirt.engine.api.restapi.resource.BaseBackendResource$WebFaultException Later we found that assigning an Admin role to the user's account at the data center level with no permissions enabled permitted API access. So the user was able to make requests to /api/ URLs and get data and was able to log into the oVirt administration portal but was unable to take further action. So my questions are: - Is this expected behavior? Is there some smaller (less permissive) change in privileges I can use to bring about the same behavior? - Is there some place where such behavior is documented? I couldn't find any. The documentation on permissions on the RHEV docs only mentions the overall impact of using specific roles and permissions and says nothing about API access consequences or "Admin" roles with no permissions. My initial assumption was that any user with credentials would be able to make API requests, but that the corresponding API responses would be filtered based on what the user had privileges to see just as with the User Portal. Thanks! [1] A full trace can be found at http://pastebin.com/czcfQkYL -- Jonathan Daugherty Software Engineer Galois, Inc.

3 7

[Engine-devel] REST-API: Problem with additional DELETE action at collection level
by Shubhendu Tripathi 11 Nov '13

11 Nov '13

This is a multi-part message in MIME format. --------------050509030900000404030401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi All, There is a DELETE action defined at collection level for Gluster Bricks with signature - /@DELETE public////Response//remove//(//GlusterBricks//bricks//);/ Recently we had needed a commit action to remove migrated bricks. After multiple rounds of discussion on introducing a commit action to remove migrated bricks we introduced a DELETE action [1] which accepts a boolean parameter isForce. If the parameter is set to /true/, forced deletion of bricks happens without any data migration. And if the parameter is not set or set to /false,/ the deletion is meant for a brick on which migration has already taken place. To achieve the above functionality we introduced another DELETE action with new signature as below and also marked the first action as deprecated - /@DELETE public////Response//remove//(//Action//action//);/ The problem arises now as the new api works fine for all possible scenarios with below input structure - / //<action>// // <force>true/false</force>// // <bricks>// // <brick>// // <name>//brick1-name</name>// // <name>brick2-name</name>// // </brick>// // </bricks>// //</action>/ BUT after these change backward compatibility is broken and the old api does not work. If we try invoking old DELETE with bricks as input parameter as below, it still invokes the new api and gives an error saying "Invalid parameter". / //<bricks> <brick id="brick1-id"/> // <brick id="brick2-id"/> </bricks>/ Kindly suggest a solution around the same. *PS:* Both the actions are defined at collection level (//api/clusters/<cluster-id>/glustervolumes/<volume-id>/bricks/) [1]: http://gerrit.ovirt.org/#/c/21043/ Thanks and Regards, Shubhendu --------------050509030900000404030401 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> There is a DELETE action defined at collection level for Gluster Bricks with signature -<br> <br> <font color="#3333ff"><i><span class="kwd">@DELETE<br> public</span></i><i><span class="pln"> </span></i><i><span class="typ">Response</span></i><i><span class="pln"> remove</span></i><i><span class="pun">(</span></i><i><span class="typ">GlusterBricks</span></i><i><span class="pln"> bricks</span></i></font><span class="pun"><font color="#3333ff"><i>);</i></font><br> <br> Recently we had needed a commit action to remove migrated bricks. <br> After multiple rounds of discussion on introducing a commit action to remove migrated bricks we introduced a DELETE action [1] which accepts a boolean parameter isForce.<br> If the parameter is set to <i>true</i>, forced deletion of bricks happens without any data migration.<br> And if the parameter is not set or set to <i>false,</i> the deletion is meant for a brick on which migration has already taken place.<br> <br> To achieve the above functionality we introduced another DELETE action with new signature as below and </span><span class="pun"><span class="pun"><span class="pun">also marked the first action as deprecated</span></span> -<br> <br> </span><span class="pun"><font color="#3333ff"><i><span class="kwd">@DELETE<br> public</span></i><i><span class="pln"> </span></i><i><span class="typ">Response</span></i><i><span class="pln"> remove</span></i><i><span class="pun">(</span></i><i><span class="typ">Action</span></i><i><span class="pln"> action</span></i></font><span class="pun"><font color="#3333ff"><i>);</i></font><br> <br> The problem arises now as the new api works fine for all possible scenarios with below input structure -<br> <font color="#3333ff"><i><br> </i><i><action></i><i><br> </i><i>    <force>true/false</force></i><i><br> </i><i>    <bricks></i><i><br> </i><i>        <brick></i><i><br> </i><i>            <name></i><i>brick1-name</name></i><i><br> </i></font></span></span><span class="pun"><span class="pun"><font color="#3333ff"><i><span class="pun"><span class="pun">            <name>brick2-name</name></span></span></i><i><br> </i><i>        </brick></i><i><br> </i><i>    </bricks></i><i><br> </i><i></action></i></font><br> <br> BUT after these change backward compatibility is broken and the old api does not work.<br> If we try invoking old DELETE with bricks as input parameter as below, it still invokes the new api and gives an error saying "<font color="#ff0000">Invalid parameter</font>".<br> <font color="#3333ff"><i><br> </i></font></span></span><font color="#3333ff"><i><span class="pun"><span class="pun"><span class="pun"><span class="pun"><bricks><br>     <brick id="brick1-id"/><br> </span></span></span></span></i></font><span class="pun"><span class="pun"><font color="#3333ff"><i><span class="pun"><span class="pun"><span class="pun"><span class="pun"><span class="pun"><span class="pun">    <brick id="brick2-id"/></span></span></span></span><br> </bricks></span></span></i></font><br> <br> Kindly suggest a solution around the same.<br> <br> <b>PS:</b> Both the actions are defined at collection level (<font color="#3333ff"><i>/api/clusters/<cluster-id>/glustervolumes/<volume-id>/bricks</i></font>)<br> <br> [1]: <a href="http://gerrit.ovirt.org/#/c/21043/">http://gerrit.ovirt.org/#/c/21043/</a><br> <br> Thanks and Regards,<br> Shubhendu<br> <br> <br> </span></span> </body> </html> --------------050509030900000404030401--

3 8

[Engine-devel] Custom properties per device + vNIC profile = not working (< 3.3)
by Mike Kolesnik 11 Nov '13

11 Nov '13

------=_Part_29121434_1238593392.1384156173914 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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. 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. 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. I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=1028757 for this, however I also want to discuss the situation: 1. As a user, I can't set custom properties for level < 3.3 which is not good. 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 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. Regards, Mike ------=_Part_29121434_1238593392.1384156173914 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: times new roman, new york, times, se= rif; font-size: 12pt; color: #000000"><div>Hi,<br></div><div><br></div><div= >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.<br></div><div>Fr= om what I saw the configuration value for custom properties (CustomDevicePr= operties) is split into 4, one per each version (3.0, 3.1, 3.2, 3.3).<br></= div><div>Since vNIC profile is located under the DC tree, it takes the DC v= ersion - 3.2 in this specific case.<br></div><div><br></div><div>I tried to= set the config value for 3.2 but got:<br></div><div>$ engine-config -s Cus= tomDeviceProperties=3D"{type=3Dinterface;prop=3D{myProp=3D[a-zA-Z0-9-]+}}" = --cver=3D3.2<br>Cannot set value {type=3Dinterface;prop=3D{myProp=3D[a-zA-Z= 0-9-]+}} to key CustomDeviceProperties. Device custom properties are not su= pported in version 3.2<br><br></div><div>This is already not very good, sin= ce in a 3.2 DC there can be 3.3 clusters with 3.3 hosts that do support cus= tom device properties.<br></div><div><br></div><div>I also tried to alter t= he config value in the DB directly, but the custom properties code ignored = it since custom properties are not supported in 3.2.<br></div><div>So, de f= acto, I have no reasonable way as a user to define custom device properties= to use for my vNIC profiles in DC < 3.3.<br></div><div><br></div><div>I= opened the bug <a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D10= 28757">https://bugzilla.redhat.com/show_bug.cgi?id=3D1028757</a> for this, = however I also want to discuss the situation:</div><div><br></div><div>1. A= s a user, I can't set custom properties for level < 3.3 which is not goo= d.<br></div><div>    Removing the blocking, and loading cust= om properties for all versions would fix the bug and allow using custom dev= ice properties for older versions, the reasonable place to block this would= be running a VM (or plugging a device).<br></div><div>    B= asically this is the lesser issue..<br></div><div><br></div><div>2. I just = don't see the added value of splitting the definition of the properties per= level..<br></div><div>    The custom properties are extensi= ons 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 ve= rsion, cluster version?) would make any difference - either the VM can util= ize the extension given some state of the system, or it can't, but the dete= rmining factor is not the version but rather the availability of the extens= ion.<br></div><div>    For example, I can have a hook for vN= IC altering some property installed on host A and not host B, if the VM run= s on host A it will get this capability and on host B it won't, regardless = the DC version the VM is in.<br></div><div><br></div><div>  &nbsp= ; This is not to say we shouldn't block custom properties on the engine-VDS= M API level since it's only available since 3.3, but this is handled by ano= ther config value (SupportCustomDeviceProperties) which is not alterable by= the user.<br></div><div>    So basically, I think splitting= the value per version is over complication and see no added value to the u= sers, just more maintenance should they choose to use this feature.<br></di= v><div><br></div><div>Your thoughts please.<br></div><div><br></div><div><s= pan name=3D"x"></span>Regards,<br>Mike<span name=3D"x"></span><br></div><di= v><br></div></div></body></html> ------=_Part_29121434_1238593392.1384156173914--

1 0

[Engine-devel] oVirt UI plugins feature announcements
by Vojtech Szocs 08 Nov '13

08 Nov '13

Hello everyone, I'd like to share some important updates on oVirt UI plugins feature. First of all, UI plugins wiki [1] is finally complete. API reference (application events, API functions, API options, entity types) now includes all the details and snippets of example code. I've also added section "Why load plugins via iframe element?" explaining reasons behind this design decision. [1] http://www.ovirt.org/Features/UIPlugins You might have noticed the changes in oVirt Engine URI layout [2], these are already reflected in UI plugins wiki. For existing plugins, this means changing URLs like this: /webadmin/webadmin/plugin/ExamplePlugin/start.html to this: /ovirt-engine/webadmin/plugin/ExamplePlugin/start.html [2] http://gerrit.ovirt.org/#/c/20473/ We're planning to merge patch "Improve UI Plugin vs. REST API integration" [http://gerrit.ovirt.org/#/c/20404/] soon, please review the change outlined in commit message, let me know if you have any questions. Last but not least, oVirt Space Shooter (a.k.a UI plugins crash course) wiki [3] has been updated to reflect changes mentioned above. [3] http://www.ovirt.org/Tutorial/UIPlugins/CrashCourse Regards, Vojtech

2 1

[Engine-devel] Browsing source repository
by Bob Doolittle 07 Nov '13

07 Nov '13

Hi folks, Do we have gitweb installed for the ovirt-engine repo, or is there any other way of browsing the source repository without cloning the entire thing? Is there a description of the various branches in the ovirt-engine repository? If I wanted to build the 3.3 source is the ovirt-engine-3.3 branch sufficient? I'm afraid I am new to git and also to general source/build conventions in place for Linux community projects, so sorry if my questions are naive (I come from a long Unix development background but no FOSS projects so far). I'm familiar with sccs, cvs, svn, and a little hg, but not git (yet). Thanks, Bob P.S. I'll be studying the User Portal primarily

3 2

Re: [Engine-devel] [UX] how to design a bar/line chart?
by Justin Hammond 06 Nov '13

06 Nov '13

Not directly related, but it would be good if the UI could also display disk activity per VM and overall for a host. I've got a few disk intensive VM's or the occasional memory starved VM that kills disk throughput for other VM's. it's always a struggle to identify them , so something in the UI would help me as a admin Sent from my iPhone On 6 Nov, 2013, at 11:45 PM, "Alexander Wels" <awels(a)redhat.com> wrote: > I suppose we need to answer a few questions before we can go into which > library is better: > > 1. Do we mind sending data over to Google so Google can render images for us. > 2. Are we fine with just an image being displayed in the grid? If we aren't > okay with #1, we will have to create some sort of servlet to generate the > images. > 3. Do we want the client to render the spark lines using javascript? > 4. Do we want interactivity with these visualizations? For instance if I move > my mouse over the spark line, does the value displayed change? > 5. Can we display whatever we choice in our current grid implementation? I > know the amount of javascript we can apply to it is somewhat limited right > now. > 6. Any other consideration I am not thinking of? > > Alexander > > On Wednesday, November 06, 2013 11:03:06 AM Malini Rao wrote: >> Is this a possibility? Looks nicer. http://style.org/chartapi/sparklines/ >> >> ----- Original Message ----- >> From: "Alexander Wels" <awels(a)redhat.com> >> To: engine-devel(a)ovirt.org >> Cc: "Malini Rao" <mrao(a)redhat.com>, "Tomas Jelinek" <tjelinek(a)redhat.com>, >> "Eldan Hildesheim" <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com> Sent: >> Wednesday, November 6, 2013 10:46:01 AM >> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? >> >> Maybe gchart is an option? Examples available here [1] one of the available >> charts is a spark line. I just don't know how well that will play with our >> grid implementation. >> >> [1] >> http://clientsidegchart.googlecode.com/svn/trunk/javadoc/com/googlecode/gcha >> rt/client/package-summary.html#ChartGallery >> On Wednesday, November 06, 2013 10:24:56 AM Malini Rao wrote: >>> Hey all, >>> >>> Comments inline- >>> >>> >>> >>> ----- Original Message ----- >>> >>>> From: "Tomas Jelinek" <tjelinek(a)redhat.com> >>>> To: "Einav Cohen" <ecohen(a)redhat.com> >>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan Hildesheim" >>>> <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>, "Malini Rao" >>>> <mrao(a)redhat.com>, "Martin Polednik" <mpoledni(a)redhat.com> Sent: >>>> Wednesday, November 6, 2013 9:58:03 AM >>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? >>>> >>>> Hi Einav, >>>> >>>> ----- Original Message ----- >>>> >>>>> From: "Einav Cohen" <ecohen(a)redhat.com> >>>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com> >>>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Eldan Hildesheim" >>>>> <ehildesh(a)redhat.com>, "info" <info(a)eldanet.com>, >>>>> "Malini Rao" <mrao(a)redhat.com> >>>>> Sent: Wednesday, November 6, 2013 3:26:15 PM >>>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? >>>>> >>>>> Hi Tomas, >>>>> >>>>> Like Itamar, I think that a line chart is a better idea, and that a >>>>> chart per monitored fact (rather than a combined chart) is better. >>>> >>>> OK >>> >>> Based on the original request in the bug, it seems like Itamar is looking >>> for a trend rather than just one data point. I think we are thinking along >>> the correct lines here with a line graph but I think more specifically, we >>> should consider sparklines - >>> http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR. Agree >>> that we should have one sparkline per fact but we may have to see how this >>> looks when multiple sparklines reside in columns next to each other. See >>> example of a grid where there are 2 sparklines next to each other - >>> http://www.panopticon.com/Tables-Grids >>> >>>>>>> the statistics readable enough. Maybe if you hover the chart it >>>>>>> could >>>>>>> pop >>>>>>> up a bigger version of the chart? Or not needed? >>>>> >>>>> this is a nice-to-have, I think, definitely not needed. >>>> >>>> OK >>> >>> Agree. As shown in the glucose example in the Tufte link I posted above, >>> maybe all we need is to indicate the acceptable range with a band and if >>> the last point is in the range or outside, it will be clear to the user if >>> they should pay attention to it. >>> >>>>>>> - Would it be enough to have it in one color? Or should it be >>>>>>> something >>>>>>> like "the bigger the utilization the more red"? >>>>> >>>>> question is what will happen when there are a lot of "jumps": let's >>>>> say >>>>> that the graph changes from 0% to 100% to 0% to 100% and so on... what >>>>> will be painted red? the entire line, but only in the periods that it >>>>> jumps to 100%? only the parts of line that are in 100%? >>>>> maybe a single color is enough. >>>> >>>> OK >>> >>> One color with a dot to indicate the most recent or most relevant data and >>> display its value next to the sparkline >>> >>>>> I have another concern about this feature: currently, the GUI's most >>>>> frequent >>>>> refresh rate available is 5 seconds, which means that the line will >>>>> "change" >>>>> only every 5 seconds, which would be more noticeably slow when >>>>> displayed >>>>> in >>>>> a form of a line chart (not even talking about lower frequencies). >>>>> Moreover, I am not sure at what rate the VM statistics are pulled from >>>>> VDSM, >>>>> but if it is 10 seconds or 15 seconds, it means that the line in the >>>>> GUI >>>>> will >>>>> be "flat" for every 2 reads / 3 reads, which is not so good, I think. >>>>> >>>>> any thoughts around that? >>>> >>>> Good point! AFAIK the VDSM is polled each 3 seconds for basic info (e.g. >>>> the resource >>>> usage not included) and than every 5th poll (e.g. every 15 seconds) for >>>> full data >>>> (with resource usage not included). This would indeed make the graph >>>> pretty >>>> useless. >>>> >>>> Michal proposed to do some averages on the VDSM site from more frequent >>>> sampling and >>>> send this average back to engine when polled - so we would display an >>>> average after each poll (15s). >>>> >>>> I wonder if something like this is not already used on other places: >>>> @Martin, do you know about something like this? >>> >>> Why does the change in the line need to seem palpable every few seconds? I >>> think the base requirement of how accurate the data is when a user looks >>> at >>> a grid has not changed.. just the data visualization. Right? So , if the >>> refresh rate is not a problem today, why is it a problem now? Am I missing >>> something? >>> >>>>> ----- Original Message ----- >>>>> >>>>>> From: "Itamar Heim" <iheim(a)redhat.com> >>>>>> To: "Tomas Jelinek" <tjelinek(a)redhat.com>, "engine-devel" >>>>>> <engine-devel(a)ovirt.org> >>>>>> Sent: Tuesday, November 5, 2013 10:10:34 AM >>>>>> Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? >>>>>> >>>>>> On 11/05/2013 11:50 AM, Tomas Jelinek wrote: >>>>>>> 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 >>>>>>> _______________________________________________ >>>>>>> Engine-devel mailing list >>>>>>> Engine-devel(a)ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>> >>>>>> a moving trend graph (just like fedora's system monitor for >>>>>> cpu/ram/network) is what i have in mind. so a line chart. >>>>>> you could have a single chart with different lines for >>>>>> cpu/ram/network, >>>>>> or what seems to be more common, a chart per monitored fact >>>>>> _______________________________________________ >>>>>> Engine-devel mailing list >>>>>> Engine-devel(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel

2 1

[Engine-devel] [QE] 3.3.2 Release tracker
by Sandro Bonazzola 06 Nov '13

06 Nov '13

Hi, as you may know, we're planning to build oVirt 3.3.2 beta really soon and release 3.3.2 by early December. I have created a tracker bug (https://bugzilla.redhat.com/show_bug.cgi?id=1027349) for this release. Beta build will be composed in 2 weeks. The following is a list of the bugs with target 3.3.2 or 3.3: Whiteboard Bug ID Summary infra 987982 When adding a host through the REST API, the error message says that "rootPassword" is required... infra 1017267 Plaintext user passwords in async_tasks database infra 992883 VdsManager.OnTimer loads VDS instead of VdsDynamic infra 1020344 Power Managent with cisco_ucs problem infra 1009899 exportDbSchema scripts generates output file with wrong name integration 1022440 AIO - configure the AIO host to be a gluster cluster/host integration 1026926 engine-cleanup (and possible engine-setup) does not affect runtime value of shmmax integration 902979 ovirt-live - firefox doesn't trust the installed engine integration 1021805 oVirt Live - use motd to show the admin password network 1019818 Support OpenStack Havana layer 2 agent integration network 988002 [oVirt] [network] Add button shouldn't appear on specific network network 987916 [oVirt] [provider] Dialog doesn't update unless focus lost network 987999 [oVirt] [provider] Add button shouldn't appear on specific provider storage 915753 Deadlock detected during creation vms in pool storage 987917 [oVirt] [glance] API version not specified in provider dialog storage 1024449 Check the performance with lvm-2.02.100-7 virt 1007940 Cannot clone from snapshot while using GlusterFS as POSIX Storage Domain ? 991267 [RFE] Add TUI information to log file. Please set the target to 3.3.2 and add the bug to the tracker if you think that 3.3.2 should not be released without it fixed. Please also update the target to 3.3.3 or any next release for bugs that won't be in 3.3.2: it will ease gathering the blocking bugs for next releases. For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

[Engine-devel] RFE: SPICE and VNC graphics at the same time
by Frantisek Kobzik 06 Nov '13

06 Nov '13

Dear devels, I started working on a feature that allows user to run a VM with both SPICE and VNC graphics [1]. In the engine we derive the graphics server type (SPICE/VNC) from the video device (QXL/CIRRUS), which I think is wrong. These are two different things and should be treated separately. What I suggest is to split that configuration in vm_static into two fields: 1, (already existing) Display type with values QXL or CIRRUS 2, (new) Graphics types - enum or comma-separated string that indicates that the VM should be run with 'spice'/'vnc'/'spice,vnc'/'auto' (the last means that the type will be derived from the video device which is current behavior. The feature would consist of three patches: - vdsm - add new field in vm.conf with information about graphics types of a vm. - engine backend - add graphics types to VM and corresponding entities, adjust xml rpc communication. - engine frontend - "only" adjust the ui. The patches would be backwards compatible with older engine/vdsm versions. There are some things that must be taken into account, mostly it's about differences in SPICE/VNC supported features (like multimonitors, single qxl, smartcard, migration...). e.g. if you run a vm with both graphic types together the engine should probably disallow some spice features. But this is more of an implementation detail. Feel free to reply if you have anything to say about this feature. Cheers, Franta. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=976044

3 3

[Engine-devel] Missing: Always up-to-date documentation of oVirt
by David Jaša 05 Nov '13

05 Nov '13

--=-ln9kcnV6W2ZIoMc8ulrR Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, The oVirt project made a great progress in last two releases, who doesn't believe, check Itamar's talk from recent KVM Forum. :) There is a downside to that positive trend though: oVirt has become too large for one person to know all its feautures in detail (save for full-time managers of course). The only sources currently are feature pages that tend to get outdated fairly quickly after their respective feature initial implementation, and release notes. This means that user evaluating oVirt or user looking for particular feature has to cycle through release notes of several versions, go through prospective feature pages or try luck with hopefully suitable full text query. RHEV/RHS documentation is good but not perfect either because it may lack some feature available upstream and it also has some for latest features. oVirt should present itself better than now in this respect. Full-blown documentation such as the one for RHEV/RHS is out of question IMO as it requires steady effort of handful of people to keep it up-to date and covered. What IMO is feasible though is something like what libvirt does - keep page/pages such as [1] that enumerates features with a short description and note of version since when the feature was available. It is feasible because the required run-time effort on single person is quite low: when the feature is added or heavily modified, a description of similar size to DocText of RFE bug has to be added/updated in the documentation page. There is just one problem in getting there: agree if the problem really exists and devote resources to record current state of affairs. There is also one technical catch: if the documentation is to be consumable by downstreams, the "available since" notes have to be in common format that can be machine-converted downstream to matching d/s versions. I personally can't do much more than spin up a discussion and probably write about area I know, so I hope that this email can trigger actual actions by Someone Else leading to ultimate goal.... Cheers, David [1] http://libvirt.org/formatdomain.html --=20 David Ja=C5=A1a, RHCE SPICE QE based in Brno GPG Key: 22C33E24=20 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 --=-ln9kcnV6W2ZIoMc8ulrR Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISsjCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGOTCCBSGg AwIBAgIDBl1jMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwNDEwMTE0ODI4WhcNMTQwNDEwMTM1MDM0WjBXMRkwFwYDVQQNExAxUktWVnliSEdDZnRMWjY3 MRkwFwYDVQQDDBBkamFzYUByZWRoYXQuY29tMR8wHQYJKoZIhvcNAQkBFhBkamFzYUByZWRoYXQu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx8unM64NLnlRZujXHb0ilCaqc7KB r1MwlyCtOWAyH4M/24zvfyRQyTz4ZkHd1sMeewJ5ap1/128hLSqMY/6So5yhL6UlK3nM1r9H9PTz CiPEMZmDazIzMb/Mt/4N3kkJBLpWPFRB5aB+COcex7a4dlmnUJASVWkVwvHRmfa06anME7DTccV5 cV95FKqoRUXawopdu5W2NhailCtbQJAbMIGf9FpH+J98swAsVHdvjZkSDnZcoQIPHzoPrEBawb7C vsmCe8p7pv5Dxtx3T47FdAXJiO9u+QJkaBFjfiA9ywN8fFo3Q/Jr4vl6WqEr1SyQjgL9/dWeQSYI 8LzByChnXQIDAQABo4IC1jCCAtIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ5AqZ3fyU5HOme+iF4KA3f8RxHPjAfBgNVHSME GDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAbBgNVHREEFDASgRBkamFzYUByZWRoYXQuY29tMIIB TAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQg YWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBT dGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3Nl IGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQv MC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUF BwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3Vi LmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t LzANBgkqhkiG9w0BAQUFAAOCAQEArlvH1bAdnpLvyeMQzPtJYs65ur7cpYnrxrIZ3P/r0F7juzIU fb1S+M9sYBhalmBoZQMySlVveDYHUHPDsNJQtqUzYAJMbVTdRtviCSq3wmYtG/VJOOif11gM25u4 HcgXVuhF3di5G0CHwAIx0mjUi7fPJ3WMeFKWp550ZqpbFK/i9A5fJGfHk3MfXOhAu7vkEEjJY+gA BpFqvk134+30mP4KoXfNGZpekWvj6lS/tfaxuuSTusPcY0yIGGtJqqFtL1tRlTIoaDGiok5O0k6W pMFPtm+dGnOyKT4HQMFCaAgBOVCQFDYthuGlnUlJOP/BheuvaMfwgIqM4ir+DIqOyjCCBjkwggUh oAMCAQICAwZdYzANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4X DTEzMDQxMDExNDgyOFoXDTE0MDQxMDEzNTAzNFowVzEZMBcGA1UEDRMQMVJLVlZ5YkhHQ2Z0TFo2 NzEZMBcGA1UEAwwQZGphc2FAcmVkaGF0LmNvbTEfMB0GCSqGSIb3DQEJARYQZGphc2FAcmVkaGF0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfLpzOuDS55UWbo1x29IpQmqnOy ga9TMJcgrTlgMh+DP9uM738kUMk8+GZB3dbDHnsCeWqdf9dvIS0qjGP+kqOcoS+lJSt5zNa/R/T0 8wojxDGZg2syMzG/zLf+Dd5JCQS6VjxUQeWgfgjnHse2uHZZp1CQElVpFcLx0Zn2tOmpzBOw03HF eXFfeRSqqEVF2sKKXbuVtjYWopQrW0CQGzCBn/RaR/iffLMALFR3b42ZEg52XKECDx86D6xAWsG+ wr7JgnvKe6b+Q8bcd0+OxXQFyYjvbvkCZGgRY34gPcsDfHxaN0Pya+L5elqhK9UskI4C/f3VnkEm CPC8wcgoZ10CAwEAAaOCAtYwggLSMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUOQKmd38lORzpnvoheCgN3/EcRz4wHwYDVR0j BBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGwYDVR0RBBQwEoEQZGphc2FAcmVkaGF0LmNvbTCC AUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVk IGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUg U3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9z ZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNz MS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1 Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS8wDQYJKoZIhvcNAQEFBQADggEBAK5bx9WwHZ6S78njEMz7SWLOubq+3KWJ68ayGdz/69Be47sy FH29UvjPbGAYWpZgaGUDMkpVb3g2B1Bzw7DSULalM2ACTG1U3Ubb4gkqt8JmLRv1STjon9dYDNub uB3IF1boRd3YuRtAh8ACMdJo1Iu3zyd1jHhSlqeedGaqWxSv4vQOXyRnx5NzH1zoQLu75BBIyWPo AAaRar5Nd+Pt9Jj+CqF3zRmaXpFr4+pUv7X2sbrkk7rD3GNMiBhrSaqhbS9bUZUyKGgxoqJOTtJO lqTBT7ZvnRpzsik+B0DBQmgIATlQkBQ2LYbhpZ1JSTj/wYXrr2jH8ICKjOIq/gyKjsoxggNvMIID awIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMGXWMwCQYFKw4DAhoFAKCCAa8w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMTA1MDAwMTUyWjAj BgkqhkiG9w0BCQQxFgQUrxISTbkhz0FRsFQ+luSezjBCAhYwgaUGCSsGAQQBgjcQBDGBlzCBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBE aWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMGXWMwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwZdYzANBgkqhkiG9w0BAQEFAASCAQBsV8LEtRQT UEJQ7qWHhUTsaBOYvIbc3krAosri3Fym6p/0hl00DCS2rrR0ezpyCW54qSoXSsCikYmKNIKeewNf /yZ7TacKGTmVvHKA+U9gkd3soj5Gvv6zDJfxW0n/XewVHKsfDQhqxgCUd+UPONr7BDcw05xEBuBC GqleQ69AxWYi+5rZSfh5CycBpqg397IrAeApAQlDc/V7eXsbNYONk5+/WknQIbSITwEo4cqKCJt+ hUTDrHnr2BltjiEVlrwQ6SdpUgnnsTwtS+5l7FTJDXpALUvSb8VwoHbRXFiIeAIno+g3QmH3verk byIhET466uYcKqz1Itn+nFlQS3HlAAAAAAAA --=-ln9kcnV6W2ZIoMc8ulrR--

2 1

[Engine-devel] gerrit 2.7
by Itamar Heim 05 Nov '13

05 Nov '13

the only change i see interesting in gerrit 2.7 is: - New copyMaxScore setting for labels. Labels can be configured to copy approvals forward to the next patch set. but it's not clear on its scope, considering the mentioned changes in 2.8 release notes on same topic. I plan to upgrade gerrit to 2.7 in a couple of weeks, mainly to prepare for the 2.8 upgrade later on. gerrit 2.8 (not released yet) has these interesting changes: - Configurable external robots.txt file. (courtesy of juan hernandez) as well as: - Labels can be configured to copy scores forward to new patch sets if there is no code change. - Labels can be configured to copy scores forward to new patch sets for trivial rebases. - New button to cherry-pick the change to another branch. - When issuing a rebase via the Web UI, the committer is now the logged in user, rather than "Gerrit Code Review". - Copy reviewed flag to new patch sets for identical files. If a user has already seen and reviewed a file, the reviewed flag is forwarded on to the next patch set when the content of the file in the next patch set is identical to the reviewed file. other interesting changes in 2.8: - New change screen with completely redesigned UI and fully using the REST API. - Secondary indexing with Lucene and Solr. - Lots of new REST API endpoints. - New UI extension and JavaScript API for plugins.

1 0

[Engine-devel] Major frontend refactoring landed into master
by Vojtech Szocs 04 Nov '13

04 Nov '13

Hey guys, I've just merged patch "frontend refactor phase 2" [http://gerrit.ovirt.org/#/c/17356/] into master branch. This is the second patch in a series dedicated to improving parts of frontend code responsible for communication with Engine backend: http://www.ovirt.org/Features/Design/FrontendRefactor If you find any issues related to GUI (WebAdmin, UserPortal) - just let Alex (CC'ed) or me know and we'll fix them. Regards, Vojtech

1 0

Re: [Engine-devel] [Engine-patches] Change in ovirt-engine[master]: packaging: build: perform python validations during build
by Vojtech Szocs 04 Nov '13

04 Nov '13

Hi Alon, I'm getting an error after this patch got merged: $ make clean install-dev PREFIX="$OVIRT_OUT" JBOSS_HOME="$JBOSS_HOME" ... if [ "1" != 0 ]; then \ build/python-check.sh; \ fi build/python-check.sh: line 16: pyflakes: command not found build/python-check.sh: line 17: pep8: command not found make[1]: *** [python-validation] Error 1 make[1]: Leaving directory `/home/vszocs/work/ovirt-engine' make: *** [all-dev] Error 2 I assume "pyflakes" and "pep8" are Python packages, shouldn't README.developer mention they're required now (?) I was able to fix my problem by doing: # yum install python-pip # pip install pyflakes # pip install pep8 Vojtech ----- Original Message ----- > From: "Alon Bar-Lev" <alonbl(a)redhat.com> > Cc: "Alon Bar-Lev" <alonbl(a)redhat.com> > Sent: Sunday, November 3, 2013 1:39:24 PM > Subject: [Engine-patches] Change in ovirt-engine[master]: packaging: build: perform python validations during build > > Alon Bar-Lev has uploaded a new change for review. > > Change subject: packaging: build: perform python validations during build > ...................................................................... > > packaging: build: perform python validations during build > > Change-Id: Ie4ee9bf80b8a8a75464338bc047dd16e22f0e63b > Signed-off-by: Alon Bar-Lev <alonbl(a)redhat.com> > --- > M .gitignore > M Makefile > A build/python-check.sh.in > M ovirt-engine.spec.in > D packaging/check.sh > 5 files changed, 35 insertions(+), 15 deletions(-) > > > git pull ssh://gerrit.ovirt.org:29418/ovirt-engine refs/changes/27/20827/1 > > diff --git a/.gitignore b/.gitignore > index fb33e33..bc736d2 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -43,6 +43,7 @@ > # Files generated from templates > ########################### > ovirt-engine.spec > +build/python-check.sh > packaging/bin/engine-prolog.sh > packaging/bin/ovirt-engine-log-setup-event.sh > packaging/bin/pki-common.sh > diff --git a/Makefile b/Makefile > index 6047d31..b6063ad 100644 > --- a/Makefile > +++ b/Makefile > @@ -31,6 +31,7 @@ > BUILD_DEV=0 > BUILD_UT=1 > EXTRA_BUILD_FLAGS= > +BUILD_PYTHON_VALIDATION=1 > DEV_REBUILD=1 > DEV_BUILD_GWT_DRAFT=0 > DEV_EXTRA_BUILD_FLAGS= > @@ -41,6 +42,8 @@ > MVN=mvn > RPMBUILD=rpmbuild > PYTHON=python > +PYFLAKES=pyflakes > +PEP8=pep8 > PREFIX=/usr/local > LOCALSTATE_DIR=$(PREFIX)/var > BIN_DIR=$(PREFIX)/bin > @@ -147,11 +150,14 @@ > -e "s|@PACKAGE_VERSION@|$(PACKAGE_VERSION)|g" \ > -e "s|@DISPLAY_VERSION@|$(DISPLAY_VERSION)|g" \ > -e "s|@JBOSS_HOME@|$(JBOSS_HOME)|g" \ > + -e "s|@PEP8@|$(PEP8)|g" \ > + -e "s|@PYFLAKES@|$(PYFLAKES)|g" \ > $< > $@ > > # List of files that will be generated from templates: > GENERATED = \ > ovirt-engine.spec \ > + build/python-check.sh \ > packaging/bin/engine-prolog.sh \ > packaging/bin/ovirt-engine-log-setup-event.sh \ > packaging/bin/pki-common.sh \ > @@ -184,11 +190,13 @@ > > all: \ > generated-files \ > + python-validation \ > dbscripts-validations \ > $(BUILD_FILE) \ > $(NULL) > > generated-files: $(GENERATED) > + chmod a+x build/python-check.sh > chmod a+x packaging/services/ovirt-engine/ovirt-engine.sysv > chmod a+x > packaging/services/ovirt-engine-notifier/ovirt-engine-notifier.sysv > chmod a+x > packaging/services/ovirt-websocket-proxy/ovirt-websocket-proxy.sysv > @@ -300,6 +308,11 @@ > [ -x "$(SOURCEDIR)/$${f}" ] && MASK=0755 || MASK=0644; \ > install -m "$${MASK}" "$(SOURCEDIR)/$${f}" "$$(dirname > "$(TARGETDIR)/$${f}")"; \ > done > + > +python-validation: > + if [ "$(BUILD_PYTHON_VALIDATION)" != 0 ]; then \ > + build/python-check.sh; \ > + fi > > dbscripts-validations: > test/dbscripts/check_for_duplicate_upgrade_scripts.sh > @@ -417,6 +430,7 @@ > $(MAKE) \ > install \ > BUILD_DEV=1 \ > + BUILD_PYTHON_VALIDATION=0 \ > PYTHON_DIR="$(PREFIX)$(PYTHON_SYS_DIR)" \ > $(NULL) > > diff --git a/build/python-check.sh.in b/build/python-check.sh.in > new file mode 100755 > index 0000000..d13c820 > --- /dev/null > +++ b/build/python-check.sh.in > @@ -0,0 +1,19 @@ > +#!/bin/sh > + > +PEP8="@PEP8@" > +PYFLAKES="@PYFLAKES@" > +SRCDIR="$(dirname "$0")/.." > + > +cd "${SRCDIR}" > + > +ret=0 > +FILES="$( > + find build packaging -name '*.py' | while read f; do > + [ -e "${f}.in" ] || echo "${f}" > + done > +)" > + > +"${PYFLAKES}" ${FILES} || ret=1 > +"${PEP8}" ${FILES} || ret=1 > + > +exit ${ret} > diff --git a/ovirt-engine.spec.in b/ovirt-engine.spec.in > index af2a9c9..c06faf2 100644 > --- a/ovirt-engine.spec.in > +++ b/ovirt-engine.spec.in > @@ -110,6 +110,7 @@ > BUILD_GWT=%{ovirt_build_gwt} \\\ > BUILD_LOCALES=%{ovirt_build_locales} \\\ > BUILD_UT=%{ovirt_build_ut} \\\ > + BUILD_PYTHON_VALIDATION=0 \\\ > PACKAGE_NAME=%{name} \\\ > RPM_VERSION=%{version} \\\ > RPM_RELEASE=%{release} \\\ > diff --git a/packaging/check.sh b/packaging/check.sh > deleted file mode 100755 > index ef6e0d6..0000000 > --- a/packaging/check.sh > +++ /dev/null > @@ -1,15 +0,0 @@ > -#!/bin/sh > - > -BASE="$(dirname "$0")" > - > -FILES="$( > - find "${BASE}" -name '*.py' | while read f; do > - [ -e "${f}.in" ] || echo "${f}" > - done > -)" > - > -ret=0 > -pyflakes ${FILES} || ret=1 > -pep8 ${FILES} || ret=1 > - > -exit "${ret}" > > > -- > To view, visit http://gerrit.ovirt.org/20827 > To unsubscribe, visit http://gerrit.ovirt.org/settings > > Gerrit-MessageType: newchange > Gerrit-Change-Id: Ie4ee9bf80b8a8a75464338bc047dd16e22f0e63b > Gerrit-PatchSet: 1 > Gerrit-Project: ovirt-engine > Gerrit-Branch: master > Gerrit-Owner: Alon Bar-Lev <alonbl(a)redhat.com> > _______________________________________________ > Engine-patches mailing list > Engine-patches(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-patches >

2 1

[Engine-devel] ovirt live 1.1: 'local_vm' stuck in Wait For Launch
by Einav Cohen 03 Nov '13

03 Nov '13

------=_Part_18229105_1410910980.1383498088935 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi All, In my ovirt live 1.1 system (ran as-is, done no alterations to the system once "installed"), after attempting to run the default 'local_vm' VM, it is getting stuck on 'Wait For Launch'. I tried running the ovirt live 1.1 system for ~5 times, only in one of these times the VM has actually moved to the Powering Up / Up state when attempting to run it. Any ideas? [attached engine.log, vdsm.log] Many thanks in advance! ---- Regards, Einav ------=_Part_18229105_1410910980.1383498088935 Content-Type: text/x-log; name=vdsm.log Content-Disposition: attachment; filename=vdsm.log Content-Transfer-Encoding: base64 VGhyZWFkLTEyNTo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTI6MjUsNzA5OjpCaW5kaW5nWE1MUlBD Ojo5Nzk6OnZkczo6KHdyYXBwZXIpIGNsaWVudCBbMTAuMC4wLjFdOjpjYWxsIHZtQ3JlYXRlIHdp dGggKHsnY3VzdG9tJzoge30sICdrZXlib2FyZExheW91dCc6ICdlbi11cycsICdrdm1FbmFibGUn OiAndHJ1ZScsICdhY3BpRW5hYmxlJzogJ3RydWUnLCAnZW11bGF0ZWRNYWNoaW5lJzogJ3JoZWw2 LjQuMCcsICdjcHVUeXBlJzogJ1BlbnJ5bicsICd2bUlkJzogJzFmMGEyNzYzLTVjNDAtNGZhMy1h NTFjLWVkOTgyNzZiOGU2ZCcsICdkZXZpY2VzJzogW3snZGV2aWNlJzogJ3F4bCcsICdzcGVjUGFy YW1zJzogeyd2cmFtJzogJzY1NTM2J30sICd0eXBlJzogJ3ZpZGVvJywgJ2RldmljZUlkJzogJzUw NjIzYmUzLTAxOWUtNDI3Ni1hMWRmLTJiMWNkYjkzM2U2OSd9LCB7J2luZGV4JzogJzInLCAnaWZh Y2UnOiAnaWRlJywgJ2Jvb3RPcmRlcic6ICcxJywgJ3NwZWNQYXJhbXMnOiB7J3BhdGgnOiAnJ30s ICdyZWFkb25seSc6ICd0cnVlJywgJ2RldmljZUlkJzogJzQ5NDk0YTlhLTFmNmMtNDFhYS1hOWY1 LTE4OTQ5MmMyYmZkYicsICdwYXRoJzogJycsICdkZXZpY2UnOiAnY2Ryb20nLCAnc2hhcmVkJzog J2ZhbHNlJywgJ3R5cGUnOiAnZGlzayd9LCB7J2luZGV4JzogMCwgJ2lmYWNlJzogJ3ZpcnRpbycs ICdmb3JtYXQnOiAnY293JywgJ3R5cGUnOiAnZGlzaycsICd2b2x1bWVJRCc6ICdiY2FiYzJiYS1i N2UxLTQ3ZjktOTA5OC1iYmUxOWIwOTZhZDUnLCAnaW1hZ2VJRCc6ICdhNTQ0YzJjMy1jZjNhLTQy YzctOGUyMC0zNzEzNDRhZDIyZGEnLCAnc3BlY1BhcmFtcyc6IHt9LCAncmVhZG9ubHknOiAnZmFs c2UnLCAnZG9tYWluSUQnOiAnNWI1ZTUzMjItZGYyMi00NTE2LTg2MGItMzYxZjAwYzQ2MjMzJywg J2RldmljZUlkJzogJ2E1NDRjMmMzLWNmM2EtNDJjNy04ZTIwLTM3MTM0NGFkMjJkYScsICdwb29s SUQnOiAnOWI0NzYyNzQtN2MxYy00NzYyLThjYjQtNjk5YzI3MjliMTUyJywgJ2RldmljZSc6ICdk aXNrJywgJ3NoYXJlZCc6ICdmYWxzZScsICdwcm9wYWdhdGVFcnJvcnMnOiAnb2ZmJywgJ29wdGlv bmFsJzogJ2ZhbHNlJ30sIHsnZGV2aWNlJzogJ3Njc2knLCAnbW9kZWwnOiAndmlydGlvLXNjc2kn LCAndHlwZSc6ICdjb250cm9sbGVyJ30sIHsnbmljTW9kZWwnOiAncHYnLCAnbWFjQWRkcic6ICcw MDoxYTo0YTo3ZDplYTo3MicsICdsaW5rQWN0aXZlJzogJ3RydWUnLCAnbmV0d29yayc6ICdvdmly dG1nbXQnLCAnY3VzdG9tJzoge30sICdmaWx0ZXInOiAndmRzbS1uby1tYWMtc3Bvb2ZpbmcnLCAn c3BlY1BhcmFtcyc6IHt9LCAnZGV2aWNlSWQnOiAnMmJjOGMyZDUtMmRkNS00ZWQ2LTg2MjYtZmFk ZWZkYmQzZmUyJywgJ2RldmljZSc6ICdicmlkZ2UnLCAndHlwZSc6ICdpbnRlcmZhY2UnfSwgeydk ZXZpY2UnOiAnaWNoNicsICdzcGVjUGFyYW1zJzoge30sICd0eXBlJzogJ3NvdW5kJywgJ2Rldmlj ZUlkJzogJzZjYTI0YzgzLWUxNzUtNGEyNC05ODAzLTBkYmEwM2Q4Y2IzZid9LCB7J2RldmljZSc6 ICdtZW1iYWxsb29uJywgJ3NwZWNQYXJhbXMnOiB7J21vZGVsJzogJ3ZpcnRpbyd9LCAndHlwZSc6 ICdiYWxsb29uJywgJ2RldmljZUlkJzogJzQ2YjlmNzAyLTRiOTAtNGIwNC04NWUzLTZlMzdlOWIx MzhlOSd9XSwgJ3NtcCc6ICcxJywgJ3ZtVHlwZSc6ICdrdm0nLCAnc21hcnRjYXJkRW5hYmxlJzog J2ZhbHNlJywgJ3RpbWVPZmZzZXQnOiAnMCcsICdtZW1TaXplJzogMTAyNCwgJ3NwaWNlU3NsQ2lw aGVyU3VpdGUnOiAnREVGQVVMVCcsICdzbXBDb3Jlc1BlclNvY2tldCc6ICcxJywgJ3NwaWNlU2Vj dXJlQ2hhbm5lbHMnOiAnc21haW4sc2lucHV0cyxzY3Vyc29yLHNwbGF5YmFjayxzcmVjb3JkLHNk aXNwbGF5LHN1c2JyZWRpcixzc21hcnRjYXJkJywgJ21lbUd1YXJhbnRlZWRTaXplJzogMTAyNCwg J3ZtTmFtZSc6ICdsb2NhbF92bScsICdkaXNwbGF5JzogJ3F4bCcsICd0cmFuc3BhcmVudEh1Z2VQ YWdlcyc6ICd0cnVlJywgJ25pY2UnOiAnMCd9LCkge30gZmxvd0lEIFsxYWNiY2IxZF0KVGhyZWFk LTEyNTo6SU5GTzo6MjAxMy0xMS0wMyAxMTo1MjoyNSw3MTY6OkFQSTo6NjQxOjp2ZHM6OihfZ2V0 TmV0d29ya0lwKSBuZXR3b3JrIE5vbmU6IHVzaW5nIDAKVGhyZWFkLTEyNTo6SU5GTzo6MjAxMy0x MS0wMyAxMTo1MjoyNSw3MTc6OmNsaWVudElGOjozNjY6OnZkczo6KGNyZWF0ZVZtKSB2bUNvbnRh aW5lckxvY2sgYWNxdWlyZWQgYnkgdm0gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4 ZTZkClRocmVhZC0xMjY6OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjI1LDcyMDo6dm06OjIwMTU6 OnZtLlZtOjooX3N0YXJ0VW5kZXJseWluZ1ZtKSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMtYTUx Yy1lZDk4Mjc2YjhlNmRgOjpTdGFydApUaHJlYWQtMTI2OjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1 MjoyNSw3MjA6OnZtOjoyMDE5Ojp2bS5WbTo6KF9zdGFydFVuZGVybHlpbmdWbSkgdm1JZD1gMWYw YTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkYDo6X29uZ29pbmdDcmVhdGlvbnMgYWNx dWlyZWQKVGhyZWFkLTEyNjo6SU5GTzo6MjAxMy0xMS0wMyAxMTo1MjoyNSw3MjA6OnZtOjoyODE1 Ojp2bS5WbTo6KF9ydW4pIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2 ZGA6OlZNIHdyYXBwZXIgaGFzIHN0YXJ0ZWQKVGhyZWFkLTEyNjo6REVCVUc6OjIwMTMtMTEtMDMg MTE6NTI6MjUsNzIxOjp0YXNrOjo1Nzk6OlRhc2tNYW5hZ2VyLlRhc2s6OihfdXBkYXRlU3RhdGUp IFRhc2s9YDRkODZjN2ZhLTlhN2ItNGM0Zi1hY2E5LTJlZjA4ZGE1ZTI4N2A6Om1vdmluZyBmcm9t IHN0YXRlIGluaXQgLT4gc3RhdGUgcHJlcGFyaW5nClRocmVhZC0xMjY6OklORk86OjIwMTMtMTEt MDMgMTE6NTI6MjUsNzIxOjpsb2dVdGlsczo6NDQ6OmRpc3BhdGNoZXI6Oih3cmFwcGVyKSBSdW4g YW5kIHByb3RlY3Q6IGdldFZvbHVtZVNpemUoc2RVVUlEPSc1YjVlNTMyMi1kZjIyLTQ1MTYtODYw Yi0zNjFmMDBjNDYyMzMnLCBzcFVVSUQ9JzliNDc2Mjc0LTdjMWMtNDc2Mi04Y2I0LTY5OWMyNzI5 YjE1MicsIGltZ1VVSUQ9J2E1NDRjMmMzLWNmM2EtNDJjNy04ZTIwLTM3MTM0NGFkMjJkYScsIHZv bFVVSUQ9J2JjYWJjMmJhLWI3ZTEtNDdmOS05MDk4LWJiZTE5YjA5NmFkNScsIG9wdGlvbnM9Tm9u ZSkKVGhyZWFkLTEyNjo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTI6MjUsNzIzOjpmaWxlVm9sdW1l Ojo1MjA6OlN0b3JhZ2UuVm9sdW1lOjoodmFsaWRhdGVWb2x1bWVQYXRoKSB2YWxpZGF0ZSBwYXRo IGZvciBiY2FiYzJiYS1iN2UxLTQ3ZjktOTA5OC1iYmUxOWIwOTZhZDUKVGhyZWFkLTEyNjo6SU5G Tzo6MjAxMy0xMS0wMyAxMTo1MjoyNSw3MjU6OmxvZ1V0aWxzOjo0Nzo6ZGlzcGF0Y2hlcjo6KHdy YXBwZXIpIFJ1biBhbmQgcHJvdGVjdDogZ2V0Vm9sdW1lU2l6ZSwgUmV0dXJuIHJlc3BvbnNlOiB7 J3RydWVzaXplJzogJzEzOTI2NCcsICdhcHBhcmVudHNpemUnOiAnMjYyMTQ0J30KVGhyZWFkLTEy Njo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTI6MjUsNzI1Ojp0YXNrOjoxMTY4OjpUYXNrTWFuYWdl ci5UYXNrOjoocHJlcGFyZSkgVGFzaz1gNGQ4NmM3ZmEtOWE3Yi00YzRmLWFjYTktMmVmMDhkYTVl Mjg3YDo6ZmluaXNoZWQ6IHsndHJ1ZXNpemUnOiAnMTM5MjY0JywgJ2FwcGFyZW50c2l6ZSc6ICcy NjIxNDQnfQpUaHJlYWQtMTI2OjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MjoyNSw3MjU6OnRhc2s6 OjU3OTo6VGFza01hbmFnZXIuVGFzazo6KF91cGRhdGVTdGF0ZSkgVGFzaz1gNGQ4NmM3ZmEtOWE3 Yi00YzRmLWFjYTktMmVmMDhkYTVlMjg3YDo6bW92aW5nIGZyb20gc3RhdGUgcHJlcGFyaW5nIC0+ IHN0YXRlIGZpbmlzaGVkClRocmVhZC0xMjY6OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjI1LDcy Njo6cmVzb3VyY2VNYW5hZ2VyOjo5Mzk6OlJlc291cmNlTWFuYWdlci5Pd25lcjo6KHJlbGVhc2VB bGwpIE93bmVyLnJlbGVhc2VBbGwgcmVxdWVzdHMge30gcmVzb3VyY2VzIHt9ClRocmVhZC0xMjY6 OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjI1LDcyNjo6cmVzb3VyY2VNYW5hZ2VyOjo5NzY6OlJl c291cmNlTWFuYWdlci5Pd25lcjo6KGNhbmNlbEFsbCkgT3duZXIuY2FuY2VsQWxsIHJlcXVlc3Rz IHt9ClRocmVhZC0xMjY6OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjI1LDcyNjo6dGFzazo6OTc0 OjpUYXNrTWFuYWdlci5UYXNrOjooX2RlY3JlZikgVGFzaz1gNGQ4NmM3ZmEtOWE3Yi00YzRmLWFj YTktMmVmMDhkYTVlMjg3YDo6cmVmIDAgYWJvcnRpbmcgRmFsc2UKVGhyZWFkLTEyNjo6SU5GTzo6 MjAxMy0xMS0wMyAxMTo1MjoyNSw3MjY6OmNsaWVudElGOjozMjU6OnZkczo6KHByZXBhcmVWb2x1 bWVQYXRoKSBwcmVwYXJlZCB2b2x1bWUgcGF0aDogClRocmVhZC0xMjY6OkRFQlVHOjoyMDEzLTEx LTAzIDExOjUyOjI1LDcyNzo6dGFzazo6NTc5OjpUYXNrTWFuYWdlci5UYXNrOjooX3VwZGF0ZVN0 YXRlKSBUYXNrPWAyOGNiNGJmYi0yMGUwLTRmMDItYmJkZi04MjY1NzFiOTgyMTdgOjptb3Zpbmcg ZnJvbSBzdGF0ZSBpbml0IC0+IHN0YXRlIHByZXBhcmluZwpUaHJlYWQtMTI2OjpJTkZPOjoyMDEz LTExLTAzIDExOjUyOjI1LDcyNzo6bG9nVXRpbHM6OjQ0OjpkaXNwYXRjaGVyOjood3JhcHBlcikg UnVuIGFuZCBwcm90ZWN0OiBwcmVwYXJlSW1hZ2Uoc2RVVUlEPSc1YjVlNTMyMi1kZjIyLTQ1MTYt ODYwYi0zNjFmMDBjNDYyMzMnLCBzcFVVSUQ9JzliNDc2Mjc0LTdjMWMtNDc2Mi04Y2I0LTY5OWMy NzI5YjE1MicsIGltZ1VVSUQ9J2E1NDRjMmMzLWNmM2EtNDJjNy04ZTIwLTM3MTM0NGFkMjJkYScs IHZvbFVVSUQ9J2JjYWJjMmJhLWI3ZTEtNDdmOS05MDk4LWJiZTE5YjA5NmFkNScpClRocmVhZC0x MjY6OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjI1LDcyNzo6cmVzb3VyY2VNYW5hZ2VyOjoxOTc6 OlJlc291cmNlTWFuYWdlci5SZXF1ZXN0OjooX19pbml0X18pIFJlc05hbWU9YFN0b3JhZ2UuNWI1 ZTUzMjItZGYyMi00NTE2LTg2MGItMzYxZjAwYzQ2MjMzYFJlcUlEPWBiZmE1YzhlYS0xMDI2LTQz N2QtOTc0OC03NDA5MGRiZmEyZGVgOjpSZXF1ZXN0IHdhcyBtYWRlIGluICcvdXNyL3NoYXJlL3Zk c20vc3RvcmFnZS9oc20ucHknIGxpbmUgJzMyNDAnIGF0ICdwcmVwYXJlSW1hZ2UnClRocmVhZC0x MjY6OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjI1LDcyNzo6cmVzb3VyY2VNYW5hZ2VyOjo1NDE6 OlJlc291cmNlTWFuYWdlcjo6KHJlZ2lzdGVyUmVzb3VyY2UpIFRyeWluZyB0byByZWdpc3RlciBy ZXNvdXJjZSAnU3RvcmFnZS41YjVlNTMyMi1kZjIyLTQ1MTYtODYwYi0zNjFmMDBjNDYyMzMnIGZv ciBsb2NrIHR5cGUgJ3NoYXJlZCcKVGhyZWFkLTEyNjo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTI6 MjUsNzI4OjpyZXNvdXJjZU1hbmFnZXI6OjYwMDo6UmVzb3VyY2VNYW5hZ2VyOjoocmVnaXN0ZXJS ZXNvdXJjZSkgUmVzb3VyY2UgJ1N0b3JhZ2UuNWI1ZTUzMjItZGYyMi00NTE2LTg2MGItMzYxZjAw YzQ2MjMzJyBpcyBmcmVlLiBOb3cgbG9ja2luZyBhcyAnc2hhcmVkJyAoMSBhY3RpdmUgdXNlcikK VGhyZWFkLTEyNjo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTI6MjUsNzI4OjpyZXNvdXJjZU1hbmFn ZXI6OjIzNzo6UmVzb3VyY2VNYW5hZ2VyLlJlcXVlc3Q6OihncmFudCkgUmVzTmFtZT1gU3RvcmFn ZS41YjVlNTMyMi1kZjIyLTQ1MTYtODYwYi0zNjFmMDBjNDYyMzNgUmVxSUQ9YGJmYTVjOGVhLTEw MjYtNDM3ZC05NzQ4LTc0MDkwZGJmYTJkZWA6OkdyYW50ZWQgcmVxdWVzdApUaHJlYWQtMTI2OjpE RUJVRzo6MjAxMy0xMS0wMyAxMTo1MjoyNSw3Mjg6OnRhc2s6OjgxMTo6VGFza01hbmFnZXIuVGFz azo6KHJlc291cmNlQWNxdWlyZWQpIFRhc2s9YDI4Y2I0YmZiLTIwZTAtNGYwMi1iYmRmLTgyNjU3 MWI5ODIxN2A6Ol9yZXNvdXJjZXNBY3F1aXJlZDogU3RvcmFnZS41YjVlNTMyMi1kZjIyLTQ1MTYt ODYwYi0zNjFmMDBjNDYyMzMgKHNoYXJlZCkKVGhyZWFkLTEyNjo6REVCVUc6OjIwMTMtMTEtMDMg MTE6NTI6MjUsNzI4Ojp0YXNrOjo5NzQ6OlRhc2tNYW5hZ2VyLlRhc2s6OihfZGVjcmVmKSBUYXNr PWAyOGNiNGJmYi0yMGUwLTRmMDItYmJkZi04MjY1NzFiOTgyMTdgOjpyZWYgMSBhYm9ydGluZyBG YWxzZQpUaHJlYWQtMTI1OjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MjoyNSw3Mjk6OmNsaWVudElG OjozODA6OnZkczo6KGNyZWF0ZVZtKSBUb3RhbCBkZXNrdG9wcyBhZnRlciBjcmVhdGlvbiBvZiAx ZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmQgaXMgMQpUaHJlYWQtMTI1OjpERUJV Rzo6MjAxMy0xMS0wMyAxMTo1MjoyNSw3Mjk6OkJpbmRpbmdYTUxSUEM6Ojk4Njo6dmRzOjood3Jh cHBlcikgcmV0dXJuIHZtQ3JlYXRlIHdpdGggeydzdGF0dXMnOiB7J21lc3NhZ2UnOiAnRG9uZScs ICdjb2RlJzogMH0sICd2bUxpc3QnOiB7J3N0YXR1cyc6ICdXYWl0Rm9yTGF1bmNoJywgJ2FjcGlF bmFibGUnOiAndHJ1ZScsICdlbXVsYXRlZE1hY2hpbmUnOiAncmhlbDYuNC4wJywgJ3ZtSWQnOiAn MWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkJywgJ3BpZCc6ICcwJywgJ21lbUd1 YXJhbnRlZWRTaXplJzogMTAyNCwgJ3RpbWVPZmZzZXQnOiAnMCcsICdrZXlib2FyZExheW91dCc6 ICdlbi11cycsICdkaXNwbGF5UG9ydCc6ICctMScsICdkaXNwbGF5U2VjdXJlUG9ydCc6ICctMScs ICdzcGljZVNzbENpcGhlclN1aXRlJzogJ0RFRkFVTFQnLCAnY3B1VHlwZSc6ICdQZW5yeW4nLCAn Y3VzdG9tJzoge30sICdjbGllbnRJcCc6ICcnLCAnbmljTW9kZWwnOiAncnRsODEzOSxwdicsICdz bWFydGNhcmRFbmFibGUnOiAnZmFsc2UnLCAna3ZtRW5hYmxlJzogJ3RydWUnLCAndHJhbnNwYXJl bnRIdWdlUGFnZXMnOiAndHJ1ZScsICdkZXZpY2VzJzogW3snZGV2aWNlJzogJ3F4bCcsICdzcGVj UGFyYW1zJzogeyd2cmFtJzogJzY1NTM2J30sICd0eXBlJzogJ3ZpZGVvJywgJ2RldmljZUlkJzog JzUwNjIzYmUzLTAxOWUtNDI3Ni1hMWRmLTJiMWNkYjkzM2U2OSd9LCB7J2luZGV4JzogJzInLCAn aWZhY2UnOiAnaWRlJywgJ2Jvb3RPcmRlcic6ICcxJywgJ3NwZWNQYXJhbXMnOiB7J3BhdGgnOiAn J30sICdyZWFkb25seSc6ICd0cnVlJywgJ2RldmljZUlkJzogJzQ5NDk0YTlhLTFmNmMtNDFhYS1h OWY1LTE4OTQ5MmMyYmZkYicsICdwYXRoJzogJycsICdkZXZpY2UnOiAnY2Ryb20nLCAnc2hhcmVk JzogJ2ZhbHNlJywgJ3R5cGUnOiAnZGlzayd9LCB7J2luZGV4JzogMCwgJ2lmYWNlJzogJ3ZpcnRp bycsICdyZXFzaXplJzogJzAnLCAnZm9ybWF0JzogJ2NvdycsICd0eXBlJzogJ2Rpc2snLCAndm9s dW1lSUQnOiAnYmNhYmMyYmEtYjdlMS00N2Y5LTkwOTgtYmJlMTliMDk2YWQ1JywgJ2FwcGFyZW50 c2l6ZSc6ICcyNjIxNDQnLCAnaW1hZ2VJRCc6ICdhNTQ0YzJjMy1jZjNhLTQyYzctOGUyMC0zNzEz NDRhZDIyZGEnLCAnc3BlY1BhcmFtcyc6IHt9LCAncmVhZG9ubHknOiAnZmFsc2UnLCAnZG9tYWlu SUQnOiAnNWI1ZTUzMjItZGYyMi00NTE2LTg2MGItMzYxZjAwYzQ2MjMzJywgJ2RldmljZUlkJzog J2E1NDRjMmMzLWNmM2EtNDJjNy04ZTIwLTM3MTM0NGFkMjJkYScsICd0cnVlc2l6ZSc6ICcxMzky NjQnLCAncG9vbElEJzogJzliNDc2Mjc0LTdjMWMtNDc2Mi04Y2I0LTY5OWMyNzI5YjE1MicsICdk ZXZpY2UnOiAnZGlzaycsICdzaGFyZWQnOiAnZmFsc2UnLCAncHJvcGFnYXRlRXJyb3JzJzogJ29m ZicsICdvcHRpb25hbCc6ICdmYWxzZSd9LCB7J2RldmljZSc6ICdzY3NpJywgJ21vZGVsJzogJ3Zp cnRpby1zY3NpJywgJ3R5cGUnOiAnY29udHJvbGxlcid9LCB7J25pY01vZGVsJzogJ3B2JywgJ21h Y0FkZHInOiAnMDA6MWE6NGE6N2Q6ZWE6NzInLCAnbGlua0FjdGl2ZSc6ICd0cnVlJywgJ25ldHdv cmsnOiAnb3ZpcnRtZ210JywgJ2N1c3RvbSc6IHt9LCAnZmlsdGVyJzogJ3Zkc20tbm8tbWFjLXNw b29maW5nJywgJ3NwZWNQYXJhbXMnOiB7fSwgJ2RldmljZUlkJzogJzJiYzhjMmQ1LTJkZDUtNGVk Ni04NjI2LWZhZGVmZGJkM2ZlMicsICdkZXZpY2UnOiAnYnJpZGdlJywgJ3R5cGUnOiAnaW50ZXJm YWNlJ30sIHsnZGV2aWNlJzogJ2ljaDYnLCAnc3BlY1BhcmFtcyc6IHt9LCAndHlwZSc6ICdzb3Vu ZCcsICdkZXZpY2VJZCc6ICc2Y2EyNGM4My1lMTc1LTRhMjQtOTgwMy0wZGJhMDNkOGNiM2YnfSwg eydkZXZpY2UnOiAnbWVtYmFsbG9vbicsICdzcGVjUGFyYW1zJzogeydtb2RlbCc6ICd2aXJ0aW8n fSwgJ3R5cGUnOiAnYmFsbG9vbicsICdkZXZpY2VJZCc6ICc0NmI5ZjcwMi00YjkwLTRiMDQtODVl My02ZTM3ZTliMTM4ZTknLCAndGFyZ2V0JzogMTA0ODU3Nn1dLCAnc21wJzogJzEnLCAndm1UeXBl JzogJ2t2bScsICdtZW1TaXplJzogMTAyNCwgJ2Rpc3BsYXlJcCc6ICcwJywgJ3NwaWNlU2VjdXJl Q2hhbm5lbHMnOiAnc21haW4sc2lucHV0cyxzY3Vyc29yLHNwbGF5YmFjayxzcmVjb3JkLHNkaXNw bGF5LHN1c2JyZWRpcixzc21hcnRjYXJkJywgJ3NtcENvcmVzUGVyU29ja2V0JzogJzEnLCAndm1O YW1lJzogJ2xvY2FsX3ZtJywgJ2Rpc3BsYXknOiAncXhsJywgJ25pY2UnOiAnMCd9fQpUaHJlYWQt MTI2OjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MjoyNSw3MzE6OmZpbGVWb2x1bWU6OjUyMDo6U3Rv cmFnZS5Wb2x1bWU6Oih2YWxpZGF0ZVZvbHVtZVBhdGgpIHZhbGlkYXRlIHBhdGggZm9yIGJjYWJj MmJhLWI3ZTEtNDdmOS05MDk4LWJiZTE5YjA5NmFkNQpUaHJlYWQtMTI2OjpJTkZPOjoyMDEzLTEx LTAzIDExOjUyOjI1LDc2NTo6aW1hZ2U6OjIxNTo6U3RvcmFnZS5JbWFnZTo6KGdldENoYWluKSBz ZFVVSUQ9NWI1ZTUzMjItZGYyMi00NTE2LTg2MGItMzYxZjAwYzQ2MjMzIGltZ1VVSUQ9YTU0NGMy YzMtY2YzYS00MmM3LThlMjAtMzcxMzQ0YWQyMmRhIGNoYWluPVs8c3RvcmFnZS5maWxlVm9sdW1l LkZpbGVWb2x1bWUgb2JqZWN0IGF0IDB4Mjk1MGE1MD5dIApUaHJlYWQtMTI2OjpERUJVRzo6MjAx My0xMS0wMyAxMTo1MjoyNSw3NzA6OmZpbGVWb2x1bWU6OjUyMDo6U3RvcmFnZS5Wb2x1bWU6Oih2 YWxpZGF0ZVZvbHVtZVBhdGgpIHZhbGlkYXRlIHBhdGggZm9yIGJjYWJjMmJhLWI3ZTEtNDdmOS05 MDk4LWJiZTE5YjA5NmFkNQpUaHJlYWQtMTI2OjpJTkZPOjoyMDEzLTExLTAzIDExOjUyOjI1LDc3 NTo6bG9nVXRpbHM6OjQ3OjpkaXNwYXRjaGVyOjood3JhcHBlcikgUnVuIGFuZCBwcm90ZWN0OiBw cmVwYXJlSW1hZ2UsIFJldHVybiByZXNwb25zZTogeydpbmZvJzogeydwYXRoJzogJy9yaGV2L2Rh dGEtY2VudGVyLzliNDc2Mjc0LTdjMWMtNDc2Mi04Y2I0LTY5OWMyNzI5YjE1Mi81YjVlNTMyMi1k ZjIyLTQ1MTYtODYwYi0zNjFmMDBjNDYyMzMvaW1hZ2VzL2E1NDRjMmMzLWNmM2EtNDJjNy04ZTIw LTM3MTM0NGFkMjJkYS9iY2FiYzJiYS1iN2UxLTQ3ZjktOTA5OC1iYmUxOWIwOTZhZDUnLCAndm9s VHlwZSc6ICdwYXRoJ30sICdwYXRoJzogJy9yaGV2L2RhdGEtY2VudGVyLzliNDc2Mjc0LTdjMWMt NDc2Mi04Y2I0LTY5OWMyNzI5YjE1Mi81YjVlNTMyMi1kZjIyLTQ1MTYtODYwYi0zNjFmMDBjNDYy MzMvaW1hZ2VzL2E1NDRjMmMzLWNmM2EtNDJjNy04ZTIwLTM3MTM0NGFkMjJkYS9iY2FiYzJiYS1i N2UxLTQ3ZjktOTA5OC1iYmUxOWIwOTZhZDUnLCAnY2hhaW4nOiBbeydwYXRoJzogJy9yaGV2L2Rh dGEtY2VudGVyLzliNDc2Mjc0LTdjMWMtNDc2Mi04Y2I0LTY5OWMyNzI5YjE1Mi81YjVlNTMyMi1k ZjIyLTQ1MTYtODYwYi0zNjFmMDBjNDYyMzMvaW1hZ2VzL2E1NDRjMmMzLWNmM2EtNDJjNy04ZTIw LTM3MTM0NGFkMjJkYS9iY2FiYzJiYS1iN2UxLTQ3ZjktOTA5OC1iYmUxOWIwOTZhZDUnLCAnZG9t YWluSUQnOiAnNWI1ZTUzMjItZGYyMi00NTE2LTg2MGItMzYxZjAwYzQ2MjMzJywgJ3ZtVm9sSW5m byc6IHsncGF0aCc6ICcvcmhldi9kYXRhLWNlbnRlci85YjQ3NjI3NC03YzFjLTQ3NjItOGNiNC02 OTljMjcyOWIxNTIvNWI1ZTUzMjItZGYyMi00NTE2LTg2MGItMzYxZjAwYzQ2MjMzL2ltYWdlcy9h NTQ0YzJjMy1jZjNhLTQyYzctOGUyMC0zNzEzNDRhZDIyZGEvYmNhYmMyYmEtYjdlMS00N2Y5LTkw OTgtYmJlMTliMDk2YWQ1JywgJ3ZvbFR5cGUnOiAncGF0aCd9LCAndm9sdW1lSUQnOiAnYmNhYmMy YmEtYjdlMS00N2Y5LTkwOTgtYmJlMTliMDk2YWQ1JywgJ2ltYWdlSUQnOiAnYTU0NGMyYzMtY2Yz YS00MmM3LThlMjAtMzcxMzQ0YWQyMmRhJ31dfQpUaHJlYWQtMTI2OjpERUJVRzo6MjAxMy0xMS0w MyAxMTo1MjoyNSw3NzU6OnRhc2s6OjExNjg6OlRhc2tNYW5hZ2VyLlRhc2s6OihwcmVwYXJlKSBU YXNrPWAyOGNiNGJmYi0yMGUwLTRmMDItYmJkZi04MjY1NzFiOTgyMTdgOjpmaW5pc2hlZDogeydp bmZvJzogeydwYXRoJzogJy9yaGV2L2RhdGEtY2VudGVyLzliNDc2Mjc0LTdjMWMtNDc2Mi04Y2I0 LTY5OWMyNzI5YjE1Mi81YjVlNTMyMi1kZjIyLTQ1MTYtODYwYi0zNjFmMDBjNDYyMzMvaW1hZ2Vz L2E1NDRjMmMzLWNmM2EtNDJjNy04ZTIwLTM3MTM0NGFkMjJkYS9iY2FiYzJiYS1iN2UxLTQ3Zjkt OTA5OC1iYmUxOWIwOTZhZDUnLCAndm9sVHlwZSc6ICdwYXRoJ30sICdwYXRoJzogJy9yaGV2L2Rh dGEtY2VudGVyLzliNDc2Mjc0LTdjMWMtNDc2Mi04Y2I0LTY5OWMyNzI5YjE1Mi81YjVlNTMyMi1k ZjIyLTQ1MTYtODYwYi0zNjFmMDBjNDYyMzMvaW1hZ2VzL2E1NDRjMmMzLWNmM2EtNDJjNy04ZTIw LTM3MTM0NGFkMjJkYS9iY2FiYzJiYS1iN2UxLTQ3ZjktOTA5OC1iYmUxOWIwOTZhZDUnLCAnY2hh aW4nOiBbeydwYXRoJzogJy9yaGV2L2RhdGEtY2VudGVyLzliNDc2Mjc0LTdjMWMtNDc2Mi04Y2I0 LTY5OWMyNzI5YjE1Mi81YjVlNTMyMi1kZjIyLTQ1MTYtODYwYi0zNjFmMDBjNDYyMzMvaW1hZ2Vz L2E1NDRjMmMzLWNmM2EtNDJjNy04ZTIwLTM3MTM0NGFkMjJkYS9iY2FiYzJiYS1iN2UxLTQ3Zjkt OTA5OC1iYmUxOWIwOTZhZDUnLCAnZG9tYWluSUQnOiAnNWI1ZTUzMjItZGYyMi00NTE2LTg2MGIt MzYxZjAwYzQ2MjMzJywgJ3ZtVm9sSW5mbyc6IHsncGF0aCc6ICcvcmhldi9kYXRhLWNlbnRlci85 YjQ3NjI3NC03YzFjLTQ3NjItOGNiNC02OTljMjcyOWIxNTIvNWI1ZTUzMjItZGYyMi00NTE2LTg2 MGItMzYxZjAwYzQ2MjMzL2ltYWdlcy9hNTQ0YzJjMy1jZjNhLTQyYzctOGUyMC0zNzEzNDRhZDIy ZGEvYmNhYmMyYmEtYjdlMS00N2Y5LTkwOTgtYmJlMTliMDk2YWQ1JywgJ3ZvbFR5cGUnOiAncGF0 aCd9LCAndm9sdW1lSUQnOiAnYmNhYmMyYmEtYjdlMS00N2Y5LTkwOTgtYmJlMTliMDk2YWQ1Jywg J2ltYWdlSUQnOiAnYTU0NGMyYzMtY2YzYS00MmM3LThlMjAtMzcxMzQ0YWQyMmRhJ31dfQpUaHJl YWQtMTI2OjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MjoyNSw3NzU6OnRhc2s6OjU3OTo6VGFza01h bmFnZXIuVGFzazo6KF91cGRhdGVTdGF0ZSkgVGFzaz1gMjhjYjRiZmItMjBlMC00ZjAyLWJiZGYt ODI2NTcxYjk4MjE3YDo6bW92aW5nIGZyb20gc3RhdGUgcHJlcGFyaW5nIC0+IHN0YXRlIGZpbmlz aGVkClRocmVhZC0xMjY6OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjI1LDc3NTo6cmVzb3VyY2VN YW5hZ2VyOjo5Mzk6OlJlc291cmNlTWFuYWdlci5Pd25lcjo6KHJlbGVhc2VBbGwpIE93bmVyLnJl bGVhc2VBbGwgcmVxdWVzdHMge30gcmVzb3VyY2VzIHsnU3RvcmFnZS41YjVlNTMyMi1kZjIyLTQ1 MTYtODYwYi0zNjFmMDBjNDYyMzMnOiA8IFJlc291cmNlUmVmICdTdG9yYWdlLjViNWU1MzIyLWRm MjItNDUxNi04NjBiLTM2MWYwMGM0NjIzMycsIGlzVmFsaWQ6ICdUcnVlJyBvYmo6ICdOb25lJz59 ClRocmVhZC0xMjY6OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjI1LDc3NTo6cmVzb3VyY2VNYW5h Z2VyOjo5NzY6OlJlc291cmNlTWFuYWdlci5Pd25lcjo6KGNhbmNlbEFsbCkgT3duZXIuY2FuY2Vs QWxsIHJlcXVlc3RzIHt9ClRocmVhZC0xMjY6OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjI1LDc3 Njo6cmVzb3VyY2VNYW5hZ2VyOjo2MTU6OlJlc291cmNlTWFuYWdlcjo6KHJlbGVhc2VSZXNvdXJj ZSkgVHJ5aW5nIHRvIHJlbGVhc2UgcmVzb3VyY2UgJ1N0b3JhZ2UuNWI1ZTUzMjItZGYyMi00NTE2 LTg2MGItMzYxZjAwYzQ2MjMzJwpUaHJlYWQtMTI2OjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1Mjoy NSw3NzY6OnJlc291cmNlTWFuYWdlcjo6NjM0OjpSZXNvdXJjZU1hbmFnZXI6OihyZWxlYXNlUmVz b3VyY2UpIFJlbGVhc2VkIHJlc291cmNlICdTdG9yYWdlLjViNWU1MzIyLWRmMjItNDUxNi04NjBi LTM2MWYwMGM0NjIzMycgKDAgYWN0aXZlIHVzZXJzKQpUaHJlYWQtMTI2OjpERUJVRzo6MjAxMy0x MS0wMyAxMTo1MjoyNSw3NzY6OnJlc291cmNlTWFuYWdlcjo6NjQwOjpSZXNvdXJjZU1hbmFnZXI6 OihyZWxlYXNlUmVzb3VyY2UpIFJlc291cmNlICdTdG9yYWdlLjViNWU1MzIyLWRmMjItNDUxNi04 NjBiLTM2MWYwMGM0NjIzMycgaXMgZnJlZSwgZmluZGluZyBvdXQgaWYgYW55b25lIGlzIHdhaXRp bmcgZm9yIGl0LgpUaHJlYWQtMTI2OjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MjoyNSw3NzY6OnJl c291cmNlTWFuYWdlcjo6NjQ4OjpSZXNvdXJjZU1hbmFnZXI6OihyZWxlYXNlUmVzb3VyY2UpIE5v IG9uZSBpcyB3YWl0aW5nIGZvciByZXNvdXJjZSAnU3RvcmFnZS41YjVlNTMyMi1kZjIyLTQ1MTYt ODYwYi0zNjFmMDBjNDYyMzMnLCBDbGVhcmluZyByZWNvcmRzLgpUaHJlYWQtMTI2OjpERUJVRzo6 MjAxMy0xMS0wMyAxMTo1MjoyNSw3NzY6OnRhc2s6Ojk3NDo6VGFza01hbmFnZXIuVGFzazo6KF9k ZWNyZWYpIFRhc2s9YDI4Y2I0YmZiLTIwZTAtNGYwMi1iYmRmLTgyNjU3MWI5ODIxN2A6OnJlZiAw IGFib3J0aW5nIEZhbHNlClRocmVhZC0xMjY6OklORk86OjIwMTMtMTEtMDMgMTE6NTI6MjUsNzc3 OjpjbGllbnRJRjo6MzI1Ojp2ZHM6OihwcmVwYXJlVm9sdW1lUGF0aCkgcHJlcGFyZWQgdm9sdW1l IHBhdGg6IC9yaGV2L2RhdGEtY2VudGVyLzliNDc2Mjc0LTdjMWMtNDc2Mi04Y2I0LTY5OWMyNzI5 YjE1Mi81YjVlNTMyMi1kZjIyLTQ1MTYtODYwYi0zNjFmMDBjNDYyMzMvaW1hZ2VzL2E1NDRjMmMz LWNmM2EtNDJjNy04ZTIwLTM3MTM0NGFkMjJkYS9iY2FiYzJiYS1iN2UxLTQ3ZjktOTA5OC1iYmUx OWIwOTZhZDUKVGhyZWFkLTEyNjo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTI6MjUsNzkwOjp2bTo6 Mjg3Mjo6dm0uVm06OihfcnVuKSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2 YjhlNmRgOjo8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJ1dGYtOCI/Pgo8ZG9tYWluIHR5 cGU9Imt2bSI+Cgk8bmFtZT5sb2NhbF92bTwvbmFtZT4KCTx1dWlkPjFmMGEyNzYzLTVjNDAtNGZh My1hNTFjLWVkOTgyNzZiOGU2ZDwvdXVpZD4KCTxtZW1vcnk+MTA0ODU3NjwvbWVtb3J5PgoJPGN1 cnJlbnRNZW1vcnk+MTA0ODU3NjwvY3VycmVudE1lbW9yeT4KCTx2Y3B1PjE8L3ZjcHU+Cgk8bWVt dHVuZT4KCQk8bWluX2d1YXJhbnRlZT4xMDQ4NTc2PC9taW5fZ3VhcmFudGVlPgoJPC9tZW10dW5l PgoJPGRldmljZXM+CgkJPGNoYW5uZWwgdHlwZT0idW5peCI+CgkJCTx0YXJnZXQgbmFtZT0iY29t LnJlZGhhdC5yaGV2bS52ZHNtIiB0eXBlPSJ2aXJ0aW8iLz4KCQkJPHNvdXJjZSBtb2RlPSJiaW5k IiBwYXRoPSIvdmFyL2xpYi9saWJ2aXJ0L3FlbXUvY2hhbm5lbHMvMWYwYTI3NjMtNWM0MC00ZmEz LWE1MWMtZWQ5ODI3NmI4ZTZkLmNvbS5yZWRoYXQucmhldm0udmRzbSIvPgoJCTwvY2hhbm5lbD4K CQk8Y2hhbm5lbCB0eXBlPSJ1bml4Ij4KCQkJPHRhcmdldCBuYW1lPSJvcmcucWVtdS5ndWVzdF9h Z2VudC4wIiB0eXBlPSJ2aXJ0aW8iLz4KCQkJPHNvdXJjZSBtb2RlPSJiaW5kIiBwYXRoPSIvdmFy L2xpYi9saWJ2aXJ0L3FlbXUvY2hhbm5lbHMvMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3 NmI4ZTZkLm9yZy5xZW11Lmd1ZXN0X2FnZW50LjAiLz4KCQk8L2NoYW5uZWw+CgkJPGlucHV0IGJ1 cz0icHMyIiB0eXBlPSJtb3VzZSIvPgoJCTxjaGFubmVsIHR5cGU9InNwaWNldm1jIj4KCQkJPHRh cmdldCBuYW1lPSJjb20ucmVkaGF0LnNwaWNlLjAiIHR5cGU9InZpcnRpbyIvPgoJCTwvY2hhbm5l bD4KCQk8Z3JhcGhpY3MgYXV0b3BvcnQ9InllcyIga2V5bWFwPSJlbi11cyIgbGlzdGVuPSIwIiBw YXNzd2Q9IioqKioqIiBwYXNzd2RWYWxpZFRvPSIxOTcwLTAxLTAxVDAwOjAwOjAxIiBwb3J0PSIt MSIgdGxzUG9ydD0iLTEiIHR5cGU9InNwaWNlIj4KCQkJPGNoYW5uZWwgbW9kZT0ic2VjdXJlIiBu YW1lPSJtYWluIi8+CgkJCTxjaGFubmVsIG1vZGU9InNlY3VyZSIgbmFtZT0iaW5wdXRzIi8+CgkJ CTxjaGFubmVsIG1vZGU9InNlY3VyZSIgbmFtZT0iY3Vyc29yIi8+CgkJCTxjaGFubmVsIG1vZGU9 InNlY3VyZSIgbmFtZT0icGxheWJhY2siLz4KCQkJPGNoYW5uZWwgbW9kZT0ic2VjdXJlIiBuYW1l PSJyZWNvcmQiLz4KCQkJPGNoYW5uZWwgbW9kZT0ic2VjdXJlIiBuYW1lPSJkaXNwbGF5Ii8+CgkJ CTxjaGFubmVsIG1vZGU9InNlY3VyZSIgbmFtZT0idXNicmVkaXIiLz4KCQkJPGNoYW5uZWwgbW9k ZT0ic2VjdXJlIiBuYW1lPSJzbWFydGNhcmQiLz4KCQk8L2dyYXBoaWNzPgoJCTxjb250cm9sbGVy IG1vZGVsPSJ2aXJ0aW8tc2NzaSIgdHlwZT0ic2NzaSIvPgoJCTx2aWRlbz4KCQkJPG1vZGVsIGhl YWRzPSIxIiB0eXBlPSJxeGwiIHZyYW09IjY1NTM2Ii8+CgkJPC92aWRlbz4KCQk8aW50ZXJmYWNl IHR5cGU9ImJyaWRnZSI+CgkJCTxtYWMgYWRkcmVzcz0iMDA6MWE6NGE6N2Q6ZWE6NzIiLz4KCQkJ PG1vZGVsIHR5cGU9InZpcnRpbyIvPgoJCQk8c291cmNlIGJyaWRnZT0ib3ZpcnRtZ210Ii8+CgkJ CTxmaWx0ZXJyZWYgZmlsdGVyPSJ2ZHNtLW5vLW1hYy1zcG9vZmluZyIvPgoJCQk8bGluayBzdGF0 ZT0idXAiLz4KCQk8L2ludGVyZmFjZT4KCQk8ZGlzayBkZXZpY2U9ImNkcm9tIiBzbmFwc2hvdD0i bm8iIHR5cGU9ImZpbGUiPgoJCQk8c291cmNlIGZpbGU9IiIgc3RhcnR1cFBvbGljeT0ib3B0aW9u YWwiLz4KCQkJPHRhcmdldCBidXM9ImlkZSIgZGV2PSJoZGMiLz4KCQkJPHJlYWRvbmx5Lz4KCQkJ PHNlcmlhbC8+CgkJCTxib290IG9yZGVyPSIxIi8+CgkJPC9kaXNrPgoJCTxkaXNrIGRldmljZT0i ZGlzayIgc25hcHNob3Q9Im5vIiB0eXBlPSJmaWxlIj4KCQkJPHNvdXJjZSBmaWxlPSIvcmhldi9k YXRhLWNlbnRlci85YjQ3NjI3NC03YzFjLTQ3NjItOGNiNC02OTljMjcyOWIxNTIvNWI1ZTUzMjIt ZGYyMi00NTE2LTg2MGItMzYxZjAwYzQ2MjMzL2ltYWdlcy9hNTQ0YzJjMy1jZjNhLTQyYzctOGUy MC0zNzEzNDRhZDIyZGEvYmNhYmMyYmEtYjdlMS00N2Y5LTkwOTgtYmJlMTliMDk2YWQ1Ii8+CgkJ CTx0YXJnZXQgYnVzPSJ2aXJ0aW8iIGRldj0idmRhIi8+CgkJCTxzZXJpYWw+YTU0NGMyYzMtY2Yz YS00MmM3LThlMjAtMzcxMzQ0YWQyMmRhPC9zZXJpYWw+CgkJCTxkcml2ZXIgY2FjaGU9Im5vbmUi IGVycm9yX3BvbGljeT0ic3RvcCIgaW89InRocmVhZHMiIG5hbWU9InFlbXUiIHR5cGU9InFjb3cy Ii8+CgkJPC9kaXNrPgoJCTxzb3VuZCBtb2RlbD0iaWNoNiIvPgoJCTxtZW1iYWxsb29uIG1vZGVs PSJ2aXJ0aW8iLz4KCTwvZGV2aWNlcz4KCTxvcz4KCQk8dHlwZSBhcmNoPSJ4ODZfNjQiIG1hY2hp bmU9InJoZWw2LjQuMCI+aHZtPC90eXBlPgoJCTxzbWJpb3MgbW9kZT0ic3lzaW5mbyIvPgoJPC9v cz4KCTxzeXNpbmZvIHR5cGU9InNtYmlvcyI+CgkJPHN5c3RlbT4KCQkJPGVudHJ5IG5hbWU9Im1h bnVmYWN0dXJlciI+b1ZpcnQ8L2VudHJ5PgoJCQk8ZW50cnkgbmFtZT0icHJvZHVjdCI+b1ZpcnQg Tm9kZTwvZW50cnk+CgkJCTxlbnRyeSBuYW1lPSJ2ZXJzaW9uIj42LTQuZWw2LmNlbnRvcy4xMDwv ZW50cnk+CgkJCTxlbnRyeSBuYW1lPSJzZXJpYWwiPjdCREE4NDAxLTRBNkQtMTFDQi05MzUxLTlB MTIxMzY0MDFEMjwvZW50cnk+CgkJCTxlbnRyeSBuYW1lPSJ1dWlkIj4xZjBhMjc2My01YzQwLTRm YTMtYTUxYy1lZDk4Mjc2YjhlNmQ8L2VudHJ5PgoJCTwvc3lzdGVtPgoJPC9zeXNpbmZvPgoJPGNs b2NrIGFkanVzdG1lbnQ9IjAiIG9mZnNldD0idmFyaWFibGUiPgoJCTx0aW1lciBuYW1lPSJydGMi IHRpY2twb2xpY3k9ImNhdGNodXAiLz4KCTwvY2xvY2s+Cgk8ZmVhdHVyZXM+CgkJPGFjcGkvPgoJ PC9mZWF0dXJlcz4KCTxjcHUgbWF0Y2g9ImV4YWN0Ij4KCQk8bW9kZWw+UGVucnluPC9tb2RlbD4K CQk8dG9wb2xvZ3kgY29yZXM9IjEiIHNvY2tldHM9IjEiIHRocmVhZHM9IjEiLz4KCTwvY3B1Pgo8 L2RvbWFpbj4KCmxpYnZpcnRFdmVudExvb3A6OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjI2LDM4 Mzo6dm06OjQ3MjQ6OnZtLlZtOjooX29uTGlidmlydExpZmVjeWNsZUV2ZW50KSB2bUlkPWAxZjBh Mjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpldmVudCBTdGFydGVkIGRldGFpbCAw IG9wYXF1ZSBOb25lClRocmVhZC0xMjY6OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjI2LDQ2NTo6 c2FtcGxpbmc6OjI4NTo6dm0uVm06OihzdGFydCkgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1 MWMtZWQ5ODI3NmI4ZTZkYDo6U3RhcnQgc3RhdGlzdGljcyBjb2xsZWN0aW9uClRocmVhZC0xMjg6 OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjI2LDQ3OTo6c2FtcGxpbmc6OjMxNDo6dm0uVm06Oihy dW4pIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OlN0YXRzIHRo cmVhZCBzdGFydGVkClRocmVhZC0xMjg6OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjI2LDQ4MDo6 dGFzazo6NTc5OjpUYXNrTWFuYWdlci5UYXNrOjooX3VwZGF0ZVN0YXRlKSBUYXNrPWAwNmRlMGM2 ZC0yOGU2LTRjMjAtOTEzOS05MGMzZjQ0MGRjNmJgOjptb3ZpbmcgZnJvbSBzdGF0ZSBpbml0IC0+ IHN0YXRlIHByZXBhcmluZwpUaHJlYWQtMTI4OjpJTkZPOjoyMDEzLTExLTAzIDExOjUyOjI2LDQ4 MDo6bG9nVXRpbHM6OjQ0OjpkaXNwYXRjaGVyOjood3JhcHBlcikgUnVuIGFuZCBwcm90ZWN0OiBn ZXRWb2x1bWVTaXplKHNkVVVJRD0nNWI1ZTUzMjItZGYyMi00NTE2LTg2MGItMzYxZjAwYzQ2MjMz Jywgc3BVVUlEPSc5YjQ3NjI3NC03YzFjLTQ3NjItOGNiNC02OTljMjcyOWIxNTInLCBpbWdVVUlE PSdhNTQ0YzJjMy1jZjNhLTQyYzctOGUyMC0zNzEzNDRhZDIyZGEnLCB2b2xVVUlEPSdiY2FiYzJi YS1iN2UxLTQ3ZjktOTA5OC1iYmUxOWIwOTZhZDUnLCBvcHRpb25zPU5vbmUpClRocmVhZC0xMjg6 OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjI2LDQ4Mzo6ZmlsZVZvbHVtZTo6NTIwOjpTdG9yYWdl LlZvbHVtZTo6KHZhbGlkYXRlVm9sdW1lUGF0aCkgdmFsaWRhdGUgcGF0aCBmb3IgYmNhYmMyYmEt YjdlMS00N2Y5LTkwOTgtYmJlMTliMDk2YWQ1ClRocmVhZC0xMjg6OklORk86OjIwMTMtMTEtMDMg MTE6NTI6MjYsNDg1Ojpsb2dVdGlsczo6NDc6OmRpc3BhdGNoZXI6Oih3cmFwcGVyKSBSdW4gYW5k IHByb3RlY3Q6IGdldFZvbHVtZVNpemUsIFJldHVybiByZXNwb25zZTogeyd0cnVlc2l6ZSc6ICcx MzkyNjQnLCAnYXBwYXJlbnRzaXplJzogJzI2MjE0NCd9ClRocmVhZC0xMjg6OkRFQlVHOjoyMDEz LTExLTAzIDExOjUyOjI2LDQ4NTo6dGFzazo6MTE2ODo6VGFza01hbmFnZXIuVGFzazo6KHByZXBh cmUpIFRhc2s9YDA2ZGUwYzZkLTI4ZTYtNGMyMC05MTM5LTkwYzNmNDQwZGM2YmA6OmZpbmlzaGVk OiB7J3RydWVzaXplJzogJzEzOTI2NCcsICdhcHBhcmVudHNpemUnOiAnMjYyMTQ0J30KVGhyZWFk LTEyODo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTI6MjYsNDg1Ojp0YXNrOjo1Nzk6OlRhc2tNYW5h Z2VyLlRhc2s6OihfdXBkYXRlU3RhdGUpIFRhc2s9YDA2ZGUwYzZkLTI4ZTYtNGMyMC05MTM5LTkw YzNmNDQwZGM2YmA6Om1vdmluZyBmcm9tIHN0YXRlIHByZXBhcmluZyAtPiBzdGF0ZSBmaW5pc2hl ZApUaHJlYWQtMTI4OjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MjoyNiw0ODU6OnJlc291cmNlTWFu YWdlcjo6OTM5OjpSZXNvdXJjZU1hbmFnZXIuT3duZXI6OihyZWxlYXNlQWxsKSBPd25lci5yZWxl YXNlQWxsIHJlcXVlc3RzIHt9IHJlc291cmNlcyB7fQpUaHJlYWQtMTI4OjpERUJVRzo6MjAxMy0x MS0wMyAxMTo1MjoyNiw0ODU6OnJlc291cmNlTWFuYWdlcjo6OTc2OjpSZXNvdXJjZU1hbmFnZXIu T3duZXI6OihjYW5jZWxBbGwpIE93bmVyLmNhbmNlbEFsbCByZXF1ZXN0cyB7fQpUaHJlYWQtMTI4 OjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MjoyNiw0OTE6OnRhc2s6Ojk3NDo6VGFza01hbmFnZXIu VGFzazo6KF9kZWNyZWYpIFRhc2s9YDA2ZGUwYzZkLTI4ZTYtNGMyMC05MTM5LTkwYzNmNDQwZGM2 YmA6OnJlZiAwIGFib3J0aW5nIEZhbHNlClRocmVhZC0xMjY6OkRFQlVHOjoyMDEzLTExLTAzIDEx OjUyOjI2LDUwNzo6dm1DaGFubmVsczo6MTk0Ojp2ZHM6OihyZWdpc3RlcikgQWRkIGZpbGVubyA0 NSB0byBsaXN0ZW5lcidzIGNoYW5uZWxzLgpUaHJlYWQtMTI2OjpXQVJOSU5HOjoyMDEzLTExLTAz IDExOjUyOjI2LDUyMjo6dm06OjMzMjY6OnZtLlZtOjooX3JlYWRQYXVzZUNvZGUpIHZtSWQ9YDFm MGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6Ol9yZWFkUGF1c2VDb2RlIHVuc3Vw cG9ydGVkIGJ5IGxpYnZpcnQgdm0KVGhyZWFkLTEyNjo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTI6 MjYsNTUyOjp2bTo6MjAzNjo6dm0uVm06Oihfc3RhcnRVbmRlcmx5aW5nVm0pIHZtSWQ9YDFmMGEy NzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6Ol9vbmdvaW5nQ3JlYXRpb25zIHJlbGVh c2VkClZNIENoYW5uZWxzIExpc3RlbmVyOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MjoyNiw3MDU6 OnZtQ2hhbm5lbHM6OjEwMjo6dmRzOjooX2RvX2FkZF9jaGFubmVscykgZmlsZW5vIDQ1IHdhcyBh ZGRlZCB0byB1bmNvbm5lY3RlZCBjaGFubmVscy4KVk0gQ2hhbm5lbHMgTGlzdGVuZXI6OkRFQlVH OjoyMDEzLTExLTAzIDExOjUyOjI2LDcwNTo6dm1DaGFubmVsczo6MTI4Ojp2ZHM6OihfaGFuZGxl X3VuY29ubmVjdGVkKSBUcnlpbmcgdG8gY29ubmVjdCBmaWxlbm8gNDUuClZNIENoYW5uZWxzIExp c3RlbmVyOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MjoyNiw3MDU6Omd1ZXN0SUY6OjE0Nzo6dm0u Vm06OihfY29ubmVjdCkgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZk YDo6QXR0ZW1wdGluZyBjb25uZWN0aW9uIHRvIC92YXIvbGliL2xpYnZpcnQvcWVtdS9jaGFubmVs cy8xZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmQuY29tLnJlZGhhdC5yaGV2bS52 ZHNtClZNIENoYW5uZWxzIExpc3RlbmVyOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MjoyNiw3MDY6 Omd1ZXN0SUY6OjE1MDo6dm0uVm06OihfY29ubmVjdCkgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEz LWE1MWMtZWQ5ODI3NmI4ZTZkYDo6Q29ubmVjdGVkIHRvIC92YXIvbGliL2xpYnZpcnQvcWVtdS9j aGFubmVscy8xZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmQuY29tLnJlZGhhdC5y aGV2bS52ZHNtClZNIENoYW5uZWxzIExpc3RlbmVyOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1Mjoy Niw3MDc6OnZtQ2hhbm5lbHM6OjE0NDo6dmRzOjooX2hhbmRsZV91bmNvbm5lY3RlZCkgQ29ubmVj dGluZyB0byBmaWxlbm8gNDUgc3VjY2VlZGVkLgpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRFQlVH OjoyMDEzLTExLTAzIDExOjUyOjI3LDcwMDo6dm06OjU3OTo6dm0uVm06OihfZ2V0Q3B1U3RhdHMp IHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkNQVSBzdGF0cyBu b3QgYXZhaWxhYmxlOiAnTm9uZVR5cGUnIG9iamVjdCBpcyB1bnN1YnNjcmlwdGFibGUKR3Vlc3RN b25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MjoyNyw3MDA6OnZtOjo2MTM6 OnZtLlZtOjooX2dldE5ldHdvcmtTdGF0cykgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMt ZWQ5ODI3NmI4ZTZkYDo6TmV0d29yayBzdGF0cyBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1s b2NhbF92bTo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTI6MjcsNzAxOjp2bTo6NjMzOjp2bS5WbTo6 KF9nZXREaXNrU3RhdHMpIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2 ZGA6OkRpc2sgaGRjIHN0YXRzIG5vdCBhdmFpbGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpE RUJVRzo6MjAxMy0xMS0wMyAxMTo1MjoyNyw3MDE6OnZtOjo2MzM6OnZtLlZtOjooX2dldERpc2tT dGF0cykgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayB2 ZGEgc3RhdHMgbm90IGF2YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEz LTExLTAzIDExOjUyOjI3LDcwMTo6dm06OjY3Mjo6dm0uVm06OihfZ2V0RGlza0xhdGVuY3kpIHZt SWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sgaGRjIGxhdGVu Y3kgbm90IGF2YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAz IDExOjUyOjI3LDcwMTo6dm06OjY3Mjo6dm0uVm06OihfZ2V0RGlza0xhdGVuY3kpIHZtSWQ9YDFm MGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sgdmRhIGxhdGVuY3kgbm90 IGF2YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUy OjI3LDcwNDo6dm06OjU3OTo6dm0uVm06OihfZ2V0Q3B1U3RhdHMpIHZtSWQ9YDFmMGEyNzYzLTVj NDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkNQVSBzdGF0cyBub3QgYXZhaWxhYmxlOiAnTm9u ZVR5cGUnIG9iamVjdCBpcyB1bnN1YnNjcmlwdGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpE RUJVRzo6MjAxMy0xMS0wMyAxMTo1MjoyNyw3MDQ6OnZtOjo2MTM6OnZtLlZtOjooX2dldE5ldHdv cmtTdGF0cykgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkYDo6TmV0 d29yayBzdGF0cyBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1sb2NhbF92bTo6REVCVUc6OjIw MTMtMTEtMDMgMTE6NTI6MjcsNzA0Ojp2bTo6NjMzOjp2bS5WbTo6KF9nZXREaXNrU3RhdHMpIHZt SWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sgaGRjIHN0YXRz IG5vdCBhdmFpbGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAx MTo1MjoyNyw3MDU6OnZtOjo2MzM6OnZtLlZtOjooX2dldERpc2tTdGF0cykgdm1JZD1gMWYwYTI3 NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayB2ZGEgc3RhdHMgbm90IGF2YWls YWJsZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjI3LDcw NTo6dm06OjY3Mjo6dm0uVm06OihfZ2V0RGlza0xhdGVuY3kpIHZtSWQ9YDFmMGEyNzYzLTVjNDAt NGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sgaGRjIGxhdGVuY3kgbm90IGF2YWlsYWJsZQpH dWVzdE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjI3LDcwNTo6dm06 OjY3Mjo6dm0uVm06OihfZ2V0RGlza0xhdGVuY3kpIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1h NTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sgdmRhIGxhdGVuY3kgbm90IGF2YWlsYWJsZQpHdWVzdE1v bml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjMyLDcxMjo6dm06OjU3OTo6 dm0uVm06OihfZ2V0Q3B1U3RhdHMpIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgy NzZiOGU2ZGA6OkNQVSBzdGF0cyBub3QgYXZhaWxhYmxlOiAnTm9uZVR5cGUnIG9iamVjdCBpcyB1 bnN1YnNjcmlwdGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAx MTo1MjozMiw3MTI6OnZtOjo2MzM6OnZtLlZtOjooX2dldERpc2tTdGF0cykgdm1JZD1gMWYwYTI3 NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayBoZGMgc3RhdHMgbm90IGF2YWls YWJsZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjMyLDcx Mzo6dm06OjYzMzo6dm0uVm06OihfZ2V0RGlza1N0YXRzKSB2bUlkPWAxZjBhMjc2My01YzQwLTRm YTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpEaXNrIHZkYSBzdGF0cyBub3QgYXZhaWxhYmxlCkd1ZXN0 TW9uaXRvci1sb2NhbF92bTo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTI6MzIsNzEzOjp2bTo6Njcy Ojp2bS5WbTo6KF9nZXREaXNrTGF0ZW5jeSkgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMt ZWQ5ODI3NmI4ZTZkYDo6RGlzayBoZGMgbGF0ZW5jeSBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRv ci1sb2NhbF92bTo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTI6MzIsNzEzOjp2bTo6NjcyOjp2bS5W bTo6KF9nZXREaXNrTGF0ZW5jeSkgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3 NmI4ZTZkYDo6RGlzayB2ZGEgbGF0ZW5jeSBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1sb2Nh bF92bTo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTI6MzIsNzE1Ojp2bTo6NTc5Ojp2bS5WbTo6KF9n ZXRDcHVTdGF0cykgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkYDo6 Q1BVIHN0YXRzIG5vdCBhdmFpbGFibGU6ICdOb25lVHlwZScgb2JqZWN0IGlzIHVuc3Vic2NyaXB0 YWJsZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjMyLDcx Njo6dm06OjYzMzo6dm0uVm06OihfZ2V0RGlza1N0YXRzKSB2bUlkPWAxZjBhMjc2My01YzQwLTRm YTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpEaXNrIGhkYyBzdGF0cyBub3QgYXZhaWxhYmxlCkd1ZXN0 TW9uaXRvci1sb2NhbF92bTo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTI6MzIsNzE2Ojp2bTo6NjMz Ojp2bS5WbTo6KF9nZXREaXNrU3RhdHMpIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVk OTgyNzZiOGU2ZGA6OkRpc2sgdmRhIHN0YXRzIG5vdCBhdmFpbGFibGUKR3Vlc3RNb25pdG9yLWxv Y2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MjozMiw3MTY6OnZtOjo2NzI6OnZtLlZtOjoo X2dldERpc2tMYXRlbmN5KSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2Yjhl NmRgOjpEaXNrIGhkYyBsYXRlbmN5IG5vdCBhdmFpbGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3Zt OjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MjozMiw3MTY6OnZtOjo2NzI6OnZtLlZtOjooX2dldERp c2tMYXRlbmN5KSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpE aXNrIHZkYSBsYXRlbmN5IG5vdCBhdmFpbGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpERUJV Rzo6MjAxMy0xMS0wMyAxMTo1MjozNyw3MjI6OnZtOjo1Nzk6OnZtLlZtOjooX2dldENwdVN0YXRz KSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpDUFUgc3RhdHMg bm90IGF2YWlsYWJsZTogJ05vbmVUeXBlJyBvYmplY3QgaXMgdW5zdWJzY3JpcHRhYmxlCkd1ZXN0 TW9uaXRvci1sb2NhbF92bTo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTI6MzcsNzIzOjp2bTo6NjMz Ojp2bS5WbTo6KF9nZXREaXNrU3RhdHMpIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVk OTgyNzZiOGU2ZGA6OkRpc2sgaGRjIHN0YXRzIG5vdCBhdmFpbGFibGUKR3Vlc3RNb25pdG9yLWxv Y2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MjozNyw3MjM6OnZtOjo2MzM6OnZtLlZtOjoo X2dldERpc2tTdGF0cykgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZk YDo6RGlzayB2ZGEgc3RhdHMgbm90IGF2YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRF QlVHOjoyMDEzLTExLTAzIDExOjUyOjM3LDcyMzo6dm06OjY3Mjo6dm0uVm06OihfZ2V0RGlza0xh dGVuY3kpIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sg aGRjIGxhdGVuY3kgbm90IGF2YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoy MDEzLTExLTAzIDExOjUyOjM3LDcyMzo6dm06OjY3Mjo6dm0uVm06OihfZ2V0RGlza0xhdGVuY3kp IHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sgdmRhIGxh dGVuY3kgbm90IGF2YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTEx LTAzIDExOjUyOjM3LDcyNTo6dm06OjU3OTo6dm0uVm06OihfZ2V0Q3B1U3RhdHMpIHZtSWQ9YDFm MGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkNQVSBzdGF0cyBub3QgYXZhaWxh YmxlOiAnTm9uZVR5cGUnIG9iamVjdCBpcyB1bnN1YnNjcmlwdGFibGUKR3Vlc3RNb25pdG9yLWxv Y2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MjozNyw3MjY6OnZtOjo2MzM6OnZtLlZtOjoo X2dldERpc2tTdGF0cykgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZk YDo6RGlzayBoZGMgc3RhdHMgbm90IGF2YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRF QlVHOjoyMDEzLTExLTAzIDExOjUyOjM3LDcyNjo6dm06OjYzMzo6dm0uVm06OihfZ2V0RGlza1N0 YXRzKSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpEaXNrIHZk YSBzdGF0cyBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1sb2NhbF92bTo6REVCVUc6OjIwMTMt MTEtMDMgMTE6NTI6MzcsNzI2Ojp2bTo6NjcyOjp2bS5WbTo6KF9nZXREaXNrTGF0ZW5jeSkgdm1J ZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayBoZGMgbGF0ZW5j eSBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1sb2NhbF92bTo6REVCVUc6OjIwMTMtMTEtMDMg MTE6NTI6MzcsNzI2Ojp2bTo6NjcyOjp2bS5WbTo6KF9nZXREaXNrTGF0ZW5jeSkgdm1JZD1gMWYw YTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayB2ZGEgbGF0ZW5jeSBub3Qg YXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1sb2NhbF92bTo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTI6 NDIsNzMzOjp2bTo6NjMzOjp2bS5WbTo6KF9nZXREaXNrU3RhdHMpIHZtSWQ9YDFmMGEyNzYzLTVj NDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sgaGRjIHN0YXRzIG5vdCBhdmFpbGFibGUK R3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1Mjo0Miw3MzM6OnZt Ojo2MzM6OnZtLlZtOjooX2dldERpc2tTdGF0cykgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1 MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayB2ZGEgc3RhdHMgbm90IGF2YWlsYWJsZQpHdWVzdE1vbml0 b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjQyLDczNDo6dm06OjY3Mjo6dm0u Vm06OihfZ2V0RGlza0xhdGVuY3kpIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgy NzZiOGU2ZGA6OkRpc2sgaGRjIGxhdGVuY3kgbm90IGF2YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9j YWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjQyLDczNDo6dm06OjY3Mjo6dm0uVm06Oihf Z2V0RGlza0xhdGVuY3kpIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2 ZGA6OkRpc2sgdmRhIGxhdGVuY3kgbm90IGF2YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06 OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjQyLDczNjo6dm06OjYzMzo6dm0uVm06OihfZ2V0RGlz a1N0YXRzKSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpEaXNr IGhkYyBzdGF0cyBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1sb2NhbF92bTo6REVCVUc6OjIw MTMtMTEtMDMgMTE6NTI6NDIsNzM2Ojp2bTo6NjMzOjp2bS5WbTo6KF9nZXREaXNrU3RhdHMpIHZt SWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sgdmRhIHN0YXRz IG5vdCBhdmFpbGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAx MTo1Mjo0Miw3MzY6OnZtOjo2NzI6OnZtLlZtOjooX2dldERpc2tMYXRlbmN5KSB2bUlkPWAxZjBh Mjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpEaXNrIGhkYyBsYXRlbmN5IG5vdCBh dmFpbGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1Mjo0 Miw3Mzc6OnZtOjo2NzI6OnZtLlZtOjooX2dldERpc2tMYXRlbmN5KSB2bUlkPWAxZjBhMjc2My01 YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpEaXNrIHZkYSBsYXRlbmN5IG5vdCBhdmFpbGFi bGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1Mjo0Nyw3NDI6 OnZtOjo2MzM6OnZtLlZtOjooX2dldERpc2tTdGF0cykgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEz LWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayBoZGMgc3RhdHMgbm90IGF2YWlsYWJsZQpHdWVzdE1v bml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjQ3LDc0Mzo6dm06OjYzMzo6 dm0uVm06OihfZ2V0RGlza1N0YXRzKSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4 Mjc2YjhlNmRgOjpEaXNrIHZkYSBzdGF0cyBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1sb2Nh bF92bTo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTI6NDcsNzQzOjp2bTo6NjcyOjp2bS5WbTo6KF9n ZXREaXNrTGF0ZW5jeSkgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZk YDo6RGlzayBoZGMgbGF0ZW5jeSBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1sb2NhbF92bTo6 REVCVUc6OjIwMTMtMTEtMDMgMTE6NTI6NDcsNzQzOjp2bTo6NjcyOjp2bS5WbTo6KF9nZXREaXNr TGF0ZW5jeSkgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlz ayB2ZGEgbGF0ZW5jeSBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1sb2NhbF92bTo6REVCVUc6 OjIwMTMtMTEtMDMgMTE6NTI6NDcsNzQ1Ojp2bTo6NjMzOjp2bS5WbTo6KF9nZXREaXNrU3RhdHMp IHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sgaGRjIHN0 YXRzIG5vdCBhdmFpbGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0w MyAxMTo1Mjo0Nyw3NDY6OnZtOjo2MzM6OnZtLlZtOjooX2dldERpc2tTdGF0cykgdm1JZD1gMWYw YTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayB2ZGEgc3RhdHMgbm90IGF2 YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjQ3 LDc0Njo6dm06OjY3Mjo6dm0uVm06OihfZ2V0RGlza0xhdGVuY3kpIHZtSWQ9YDFmMGEyNzYzLTVj NDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sgaGRjIGxhdGVuY3kgbm90IGF2YWlsYWJs ZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjQ3LDc0Njo6 dm06OjY3Mjo6dm0uVm06OihfZ2V0RGlza0xhdGVuY3kpIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZh My1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sgdmRhIGxhdGVuY3kgbm90IGF2YWlsYWJsZQpHdWVz dE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjUyLDc1NDo6dm06OjYz Mzo6dm0uVm06OihfZ2V0RGlza1N0YXRzKSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMtYTUxYy1l ZDk4Mjc2YjhlNmRgOjpEaXNrIGhkYyBzdGF0cyBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1s b2NhbF92bTo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTI6NTIsNzU0Ojp2bTo6NjMzOjp2bS5WbTo6 KF9nZXREaXNrU3RhdHMpIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2 ZGA6OkRpc2sgdmRhIHN0YXRzIG5vdCBhdmFpbGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpE RUJVRzo6MjAxMy0xMS0wMyAxMTo1Mjo1Miw3NTQ6OnZtOjo2NzI6OnZtLlZtOjooX2dldERpc2tM YXRlbmN5KSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpEaXNr IGhkYyBsYXRlbmN5IG5vdCBhdmFpbGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6 MjAxMy0xMS0wMyAxMTo1Mjo1Miw3NTQ6OnZtOjo2NzI6OnZtLlZtOjooX2dldERpc2tMYXRlbmN5 KSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpEaXNrIHZkYSBs YXRlbmN5IG5vdCBhdmFpbGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6MjAxMy0x MS0wMyAxMTo1Mjo1Miw3NTY6OnZtOjo2MzM6OnZtLlZtOjooX2dldERpc2tTdGF0cykgdm1JZD1g MWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayBoZGMgc3RhdHMgbm90 IGF2YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUy OjUyLDc1Njo6dm06OjYzMzo6dm0uVm06OihfZ2V0RGlza1N0YXRzKSB2bUlkPWAxZjBhMjc2My01 YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpEaXNrIHZkYSBzdGF0cyBub3QgYXZhaWxhYmxl Ckd1ZXN0TW9uaXRvci1sb2NhbF92bTo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTI6NTIsNzU3Ojp2 bTo6NjcyOjp2bS5WbTo6KF9nZXREaXNrTGF0ZW5jeSkgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEz LWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayBoZGMgbGF0ZW5jeSBub3QgYXZhaWxhYmxlCkd1ZXN0 TW9uaXRvci1sb2NhbF92bTo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTI6NTIsNzU3Ojp2bTo6Njcy Ojp2bS5WbTo6KF9nZXREaXNrTGF0ZW5jeSkgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMt ZWQ5ODI3NmI4ZTZkYDo6RGlzayB2ZGEgbGF0ZW5jeSBub3QgYXZhaWxhYmxlClZNIENoYW5uZWxz IExpc3RlbmVyOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1Mjo1Niw3Mzc6OnZtQ2hhbm5lbHM6Ojkx Ojp2ZHM6OihfaGFuZGxlX3RpbWVvdXRzKSBUaW1lb3V0IG9uIGZpbGVubyA0NS4KR3Vlc3RNb25p dG9yLWxvY2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1Mjo1Nyw3NjQ6OnZtOjo2MzM6OnZt LlZtOjooX2dldERpc2tTdGF0cykgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3 NmI4ZTZkYDo6RGlzayBoZGMgc3RhdHMgbm90IGF2YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9jYWxf dm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjU3LDc2NTo6dm06OjYzMzo6dm0uVm06OihfZ2V0 RGlza1N0YXRzKSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpE aXNrIHZkYSBzdGF0cyBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1sb2NhbF92bTo6REVCVUc6 OjIwMTMtMTEtMDMgMTE6NTI6NTcsNzY1Ojp2bTo6NjcyOjp2bS5WbTo6KF9nZXREaXNrTGF0ZW5j eSkgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayBoZGMg bGF0ZW5jeSBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1sb2NhbF92bTo6REVCVUc6OjIwMTMt MTEtMDMgMTE6NTI6NTcsNzY1Ojp2bTo6NjcyOjp2bS5WbTo6KF9nZXREaXNrTGF0ZW5jeSkgdm1J ZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayB2ZGEgbGF0ZW5j eSBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1sb2NhbF92bTo6REVCVUc6OjIwMTMtMTEtMDMg MTE6NTI6NTcsNzY4Ojp2bTo6NjMzOjp2bS5WbTo6KF9nZXREaXNrU3RhdHMpIHZtSWQ9YDFmMGEy NzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sgaGRjIHN0YXRzIG5vdCBhdmFp bGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1Mjo1Nyw3 Njg6OnZtOjo2MzM6OnZtLlZtOjooX2dldERpc2tTdGF0cykgdm1JZD1gMWYwYTI3NjMtNWM0MC00 ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayB2ZGEgc3RhdHMgbm90IGF2YWlsYWJsZQpHdWVz dE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjU3LDc2ODo6dm06OjY3 Mjo6dm0uVm06OihfZ2V0RGlza0xhdGVuY3kpIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFj LWVkOTgyNzZiOGU2ZGA6OkRpc2sgaGRjIGxhdGVuY3kgbm90IGF2YWlsYWJsZQpHdWVzdE1vbml0 b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUyOjU3LDc2OTo6dm06OjY3Mjo6dm0u Vm06OihfZ2V0RGlza0xhdGVuY3kpIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgy NzZiOGU2ZGA6OkRpc2sgdmRhIGxhdGVuY3kgbm90IGF2YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9j YWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUzOjAyLDc4Mjo6dm06OjYzMzo6dm0uVm06Oihf Z2V0RGlza1N0YXRzKSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRg OjpEaXNrIGhkYyBzdGF0cyBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1sb2NhbF92bTo6REVC VUc6OjIwMTMtMTEtMDMgMTE6NTM6MDIsNzgzOjp2bTo6NjMzOjp2bS5WbTo6KF9nZXREaXNrU3Rh dHMpIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sgdmRh IHN0YXRzIG5vdCBhdmFpbGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6MjAxMy0x MS0wMyAxMTo1MzowMiw3ODM6OnZtOjo2NzI6OnZtLlZtOjooX2dldERpc2tMYXRlbmN5KSB2bUlk PWAxZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpEaXNrIGhkYyBsYXRlbmN5 IG5vdCBhdmFpbGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAx MTo1MzowMiw3ODQ6OnZtOjo2NzI6OnZtLlZtOjooX2dldERpc2tMYXRlbmN5KSB2bUlkPWAxZjBh Mjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpEaXNrIHZkYSBsYXRlbmN5IG5vdCBh dmFpbGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1Mzow Miw3ODY6OnZtOjo2MzM6OnZtLlZtOjooX2dldERpc2tTdGF0cykgdm1JZD1gMWYwYTI3NjMtNWM0 MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayBoZGMgc3RhdHMgbm90IGF2YWlsYWJsZQpH dWVzdE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUzOjAyLDc4Nzo6dm06 OjYzMzo6dm0uVm06OihfZ2V0RGlza1N0YXRzKSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMtYTUx Yy1lZDk4Mjc2YjhlNmRgOjpEaXNrIHZkYSBzdGF0cyBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRv ci1sb2NhbF92bTo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTM6MDIsNzg3Ojp2bTo6NjcyOjp2bS5W bTo6KF9nZXREaXNrTGF0ZW5jeSkgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3 NmI4ZTZkYDo6RGlzayBoZGMgbGF0ZW5jeSBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1sb2Nh bF92bTo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTM6MDIsNzg3Ojp2bTo6NjcyOjp2bS5WbTo6KF9n ZXREaXNrTGF0ZW5jeSkgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZk YDo6RGlzayB2ZGEgbGF0ZW5jeSBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1sb2NhbF92bTo6 REVCVUc6OjIwMTMtMTEtMDMgMTE6NTM6MDcsNzk1Ojp2bTo6NjMzOjp2bS5WbTo6KF9nZXREaXNr U3RhdHMpIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sg aGRjIHN0YXRzIG5vdCBhdmFpbGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6MjAx My0xMS0wMyAxMTo1MzowNyw3OTU6OnZtOjo2MzM6OnZtLlZtOjooX2dldERpc2tTdGF0cykgdm1J ZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayB2ZGEgc3RhdHMg bm90IGF2YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDEx OjUzOjA3LDc5NTo6dm06OjY3Mjo6dm0uVm06OihfZ2V0RGlza0xhdGVuY3kpIHZtSWQ9YDFmMGEy NzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sgaGRjIGxhdGVuY3kgbm90IGF2 YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUzOjA3 LDc5NTo6dm06OjY3Mjo6dm0uVm06OihfZ2V0RGlza0xhdGVuY3kpIHZtSWQ9YDFmMGEyNzYzLTVj NDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sgdmRhIGxhdGVuY3kgbm90IGF2YWlsYWJs ZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUzOjA3LDc5Nzo6 dm06OjYzMzo6dm0uVm06OihfZ2V0RGlza1N0YXRzKSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMt YTUxYy1lZDk4Mjc2YjhlNmRgOjpEaXNrIGhkYyBzdGF0cyBub3QgYXZhaWxhYmxlCkd1ZXN0TW9u aXRvci1sb2NhbF92bTo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTM6MDcsNzk3Ojp2bTo6NjMzOjp2 bS5WbTo6KF9nZXREaXNrU3RhdHMpIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgy NzZiOGU2ZGA6OkRpc2sgdmRhIHN0YXRzIG5vdCBhdmFpbGFibGUKR3Vlc3RNb25pdG9yLWxvY2Fs X3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MzowNyw3OTc6OnZtOjo2NzI6OnZtLlZtOjooX2dl dERpc2tMYXRlbmN5KSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRg OjpEaXNrIGhkYyBsYXRlbmN5IG5vdCBhdmFpbGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpE RUJVRzo6MjAxMy0xMS0wMyAxMTo1MzowNyw3OTc6OnZtOjo2NzI6OnZtLlZtOjooX2dldERpc2tM YXRlbmN5KSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpEaXNr IHZkYSBsYXRlbmN5IG5vdCBhdmFpbGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6 MjAxMy0xMS0wMyAxMTo1MzoxMiw4MDA6OnZtOjo2MzM6OnZtLlZtOjooX2dldERpc2tTdGF0cykg dm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayBoZGMgc3Rh dHMgbm90IGF2YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAz IDExOjUzOjEyLDgwMDo6dm06OjYzMzo6dm0uVm06OihfZ2V0RGlza1N0YXRzKSB2bUlkPWAxZjBh Mjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpEaXNrIHZkYSBzdGF0cyBub3QgYXZh aWxhYmxlCkd1ZXN0TW9uaXRvci1sb2NhbF92bTo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTM6MTIs ODAwOjp2bTo6NjcyOjp2bS5WbTo6KF9nZXREaXNrTGF0ZW5jeSkgdm1JZD1gMWYwYTI3NjMtNWM0 MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayBoZGMgbGF0ZW5jeSBub3QgYXZhaWxhYmxl Ckd1ZXN0TW9uaXRvci1sb2NhbF92bTo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTM6MTIsODAwOjp2 bTo6NjcyOjp2bS5WbTo6KF9nZXREaXNrTGF0ZW5jeSkgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEz LWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayB2ZGEgbGF0ZW5jeSBub3QgYXZhaWxhYmxlCkd1ZXN0 TW9uaXRvci1sb2NhbF92bTo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTM6MTIsODAyOjp2bTo6NjMz Ojp2bS5WbTo6KF9nZXREaXNrU3RhdHMpIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVk OTgyNzZiOGU2ZGA6OkRpc2sgaGRjIHN0YXRzIG5vdCBhdmFpbGFibGUKR3Vlc3RNb25pdG9yLWxv Y2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MzoxMiw4MDI6OnZtOjo2MzM6OnZtLlZtOjoo X2dldERpc2tTdGF0cykgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZk YDo6RGlzayB2ZGEgc3RhdHMgbm90IGF2YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRF QlVHOjoyMDEzLTExLTAzIDExOjUzOjEyLDgwMzo6dm06OjY3Mjo6dm0uVm06OihfZ2V0RGlza0xh dGVuY3kpIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sg aGRjIGxhdGVuY3kgbm90IGF2YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoy MDEzLTExLTAzIDExOjUzOjEyLDgwMzo6dm06OjY3Mjo6dm0uVm06OihfZ2V0RGlza0xhdGVuY3kp IHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sgdmRhIGxh dGVuY3kgbm90IGF2YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTEx LTAzIDExOjUzOjE3LDgxMDo6dm06OjYzMzo6dm0uVm06OihfZ2V0RGlza1N0YXRzKSB2bUlkPWAx ZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpEaXNrIGhkYyBzdGF0cyBub3Qg YXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1sb2NhbF92bTo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTM6 MTcsODEwOjp2bTo6NjMzOjp2bS5WbTo6KF9nZXREaXNrU3RhdHMpIHZtSWQ9YDFmMGEyNzYzLTVj NDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sgdmRhIHN0YXRzIG5vdCBhdmFpbGFibGUK R3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MzoxNyw4MTA6OnZt Ojo2NzI6OnZtLlZtOjooX2dldERpc2tMYXRlbmN5KSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMt YTUxYy1lZDk4Mjc2YjhlNmRgOjpEaXNrIGhkYyBsYXRlbmN5IG5vdCBhdmFpbGFibGUKR3Vlc3RN b25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MzoxNyw4MTA6OnZtOjo2NzI6 OnZtLlZtOjooX2dldERpc2tMYXRlbmN5KSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMtYTUxYy1l ZDk4Mjc2YjhlNmRgOjpEaXNrIHZkYSBsYXRlbmN5IG5vdCBhdmFpbGFibGUKR3Vlc3RNb25pdG9y LWxvY2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MzoxNyw4MTI6OnZtOjo2MzM6OnZtLlZt OjooX2dldERpc2tTdGF0cykgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4 ZTZkYDo6RGlzayBoZGMgc3RhdHMgbm90IGF2YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9jYWxfdm06 OkRFQlVHOjoyMDEzLTExLTAzIDExOjUzOjE3LDgxMjo6dm06OjYzMzo6dm0uVm06OihfZ2V0RGlz a1N0YXRzKSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpEaXNr IHZkYSBzdGF0cyBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1sb2NhbF92bTo6REVCVUc6OjIw MTMtMTEtMDMgMTE6NTM6MTcsODEyOjp2bTo6NjcyOjp2bS5WbTo6KF9nZXREaXNrTGF0ZW5jeSkg dm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayBoZGMgbGF0 ZW5jeSBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1sb2NhbF92bTo6REVCVUc6OjIwMTMtMTEt MDMgMTE6NTM6MTcsODEyOjp2bTo6NjcyOjp2bS5WbTo6KF9nZXREaXNrTGF0ZW5jeSkgdm1JZD1g MWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayB2ZGEgbGF0ZW5jeSBu b3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1sb2NhbF92bTo6REVCVUc6OjIwMTMtMTEtMDMgMTE6 NTM6MjIsODE5Ojp2bTo6NjMzOjp2bS5WbTo6KF9nZXREaXNrU3RhdHMpIHZtSWQ9YDFmMGEyNzYz LTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sgaGRjIHN0YXRzIG5vdCBhdmFpbGFi bGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1MzoyMiw4MjA6 OnZtOjo2MzM6OnZtLlZtOjooX2dldERpc2tTdGF0cykgdm1JZD1gMWYwYTI3NjMtNWM0MC00ZmEz LWE1MWMtZWQ5ODI3NmI4ZTZkYDo6RGlzayB2ZGEgc3RhdHMgbm90IGF2YWlsYWJsZQpHdWVzdE1v bml0b3ItbG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUzOjIyLDgyMDo6dm06OjY3Mjo6 dm0uVm06OihfZ2V0RGlza0xhdGVuY3kpIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVk OTgyNzZiOGU2ZGA6OkRpc2sgaGRjIGxhdGVuY3kgbm90IGF2YWlsYWJsZQpHdWVzdE1vbml0b3It bG9jYWxfdm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUzOjIyLDgyMDo6dm06OjY3Mjo6dm0uVm06 OihfZ2V0RGlza0xhdGVuY3kpIHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZi OGU2ZGA6OkRpc2sgdmRhIGxhdGVuY3kgbm90IGF2YWlsYWJsZQpHdWVzdE1vbml0b3ItbG9jYWxf dm06OkRFQlVHOjoyMDEzLTExLTAzIDExOjUzOjIyLDgyMjo6dm06OjYzMzo6dm0uVm06OihfZ2V0 RGlza1N0YXRzKSB2bUlkPWAxZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpE aXNrIGhkYyBzdGF0cyBub3QgYXZhaWxhYmxlCkd1ZXN0TW9uaXRvci1sb2NhbF92bTo6REVCVUc6 OjIwMTMtMTEtMDMgMTE6NTM6MjIsODIyOjp2bTo6NjMzOjp2bS5WbTo6KF9nZXREaXNrU3RhdHMp IHZtSWQ9YDFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZGA6OkRpc2sgdmRhIHN0 YXRzIG5vdCBhdmFpbGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0w MyAxMTo1MzoyMiw4MjI6OnZtOjo2NzI6OnZtLlZtOjooX2dldERpc2tMYXRlbmN5KSB2bUlkPWAx ZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpEaXNrIGhkYyBsYXRlbmN5IG5v dCBhdmFpbGFibGUKR3Vlc3RNb25pdG9yLWxvY2FsX3ZtOjpERUJVRzo6MjAxMy0xMS0wMyAxMTo1 MzoyMiw4MjI6OnZtOjo2NzI6OnZtLlZtOjooX2dldERpc2tMYXRlbmN5KSB2bUlkPWAxZjBhMjc2 My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmRgOjpEaXNrIHZkYSBsYXRlbmN5IG5vdCBhdmFp bGFibGUKVGhyZWFkLTEyODo6REVCVUc6OjIwMTMtMTEtMDMgMTE6NTM6MjYsNjcwOjp0YXNrOjo1 Nzk6OlRhc2tNYW5hZ2VyLlRhc2s6OihfdXBkYXRlU3RhdGUpIFRhc2s9YGVkNWQ2YTE4LTZhZTct NDczMi1iMzZlLTk3NzY0MmI4M2U4MWA6Om1vdmluZyBmcm9tIHN0YXRlIGluaXQgLT4gc3RhdGUg cHJlcGFyaW5nClRocmVhZC0xMjg6OklORk86OjIwMTMtMTEtMDMgMTE6NTM6MjYsNjcxOjpsb2dV dGlsczo6NDQ6OmRpc3BhdGNoZXI6Oih3cmFwcGVyKSBSdW4gYW5kIHByb3RlY3Q6IGdldFZvbHVt ZVNpemUoc2RVVUlEPSc1YjVlNTMyMi1kZjIyLTQ1MTYtODYwYi0zNjFmMDBjNDYyMzMnLCBzcFVV SUQ9JzliNDc2Mjc0LTdjMWMtNDc2Mi04Y2I0LTY5OWMyNzI5YjE1MicsIGltZ1VVSUQ9J2E1NDRj MmMzLWNmM2EtNDJjNy04ZTIwLTM3MTM0NGFkMjJkYScsIHZvbFVVSUQ9J2JjYWJjMmJhLWI3ZTEt NDdmOS05MDk4LWJiZTE5YjA5NmFkNScsIG9wdGlvbnM9Tm9uZSkKVGhyZWFkLTEyODo6REVCVUc6 OjIwMTMtMTEtMDMgMTE6NTM6MjYsNjczOjpmaWxlVm9sdW1lOjo1MjA6OlN0b3JhZ2UuVm9sdW1l OjoodmFsaWRhdGVWb2x1bWVQYXRoKSB2YWxpZGF0ZSBwYXRoIGZvciBiY2FiYzJiYS1iN2UxLTQ3 ZjktOTA5OC1iYmUxOWIwOTZhZDUKVGhyZWFkLTEyODo6SU5GTzo6MjAxMy0xMS0wMyAxMTo1Mzoy Niw2NzQ6OmxvZ1V0aWxzOjo0Nzo6ZGlzcGF0Y2hlcjo6KHdyYXBwZXIpIFJ1biBhbmQgcHJvdGVj dDogZ2V0Vm9sdW1lU2l6ZSwgUmV0dXJuIHJlc3BvbnNlOiB7J3RydWVzaXplJzogJzEzOTI2NCcs ICdhcHBhcmVudHNpemUnOiAnMjYyMTQ0J30KVGhyZWFkLTEyODo6REVCVUc6OjIwMTMtMTEtMDMg MTE6NTM6MjYsNjc0Ojp0YXNrOjoxMTY4OjpUYXNrTWFuYWdlci5UYXNrOjoocHJlcGFyZSkgVGFz az1gZWQ1ZDZhMTgtNmFlNy00NzMyLWIzNmUtOTc3NjQyYjgzZTgxYDo6ZmluaXNoZWQ6IHsndHJ1 ZXNpemUnOiAnMTM5MjY0JywgJ2FwcGFyZW50c2l6ZSc6ICcyNjIxNDQnfQpUaHJlYWQtMTI4OjpE RUJVRzo6MjAxMy0xMS0wMyAxMTo1MzoyNiw2NzU6OnRhc2s6OjU3OTo6VGFza01hbmFnZXIuVGFz azo6KF91cGRhdGVTdGF0ZSkgVGFzaz1gZWQ1ZDZhMTgtNmFlNy00NzMyLWIzNmUtOTc3NjQyYjgz ZTgxYDo6bW92aW5nIGZyb20gc3RhdGUgcHJlcGFyaW5nIC0+IHN0YXRlIGZpbmlzaGVkClRocmVh ZC0xMjg6OkRFQlVHOjoyMDEzLTExLTAzIDExOjUzOjI2LDY3NTo6cmVzb3VyY2VNYW5hZ2VyOjo5 Mzk6OlJlc291cmNlTWFuYWdlci5Pd25lcjo6KHJlbGVhc2VBbGwpIE93bmVyLnJlbGVhc2VBbGwg cmVxdWVzdHMge30gcmVzb3VyY2VzIHt9ClRocmVhZC0xMjg6OkRFQlVHOjoyMDEzLTExLTAzIDEx OjUzOjI2LDY3NTo6cmVzb3VyY2VNYW5hZ2VyOjo5NzY6OlJlc291cmNlTWFuYWdlci5Pd25lcjo6 KGNhbmNlbEFsbCkgT3duZXIuY2FuY2VsQWxsIHJlcXVlc3RzIHt9ClRocmVhZC0xMjg6OkRFQlVH OjoyMDEzLTExLTAzIDExOjUzOjI2LDY3NTo6dGFzazo6OTc0OjpUYXNrTWFuYWdlci5UYXNrOjoo X2RlY3JlZikgVGFzaz1gZWQ1ZDZhMTgtNmFlNy00NzMyLWIzNmUtOTc3NjQyYjgzZTgxYDo6cmVm IDAgYWJvcnRpbmcgRmFsc2UKVk0gQ2hhbm5lbHMgTGlzdGVuZXI6OkRFQlVHOjoyMDEzLTExLTAz IDExOjUzOjI2LDc3MTo6dm1DaGFubmVsczo6OTE6OnZkczo6KF9oYW5kbGVfdGltZW91dHMpIFRp bWVvdXQgb24gZmlsZW5vIDQ1LgoK ------=_Part_18229105_1410910980.1383498088935 Content-Type: text/x-log; name=engine.log Content-Disposition: attachment; filename=engine.log Content-Transfer-Encoding: base64 MjAxMy0xMS0wMyAxMTo1NjowMyw1NjggSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwu UnVuVm1Db21tYW5kXSAoYWpwLS0xMjcuMC4wLjEtODcwMi0zKSBbMzY3ZjM0ZV0gTG9jayBBY3F1 aXJlZCB0byBvYmplY3QgRW5naW5lTG9jayBbZXhjbHVzaXZlTG9ja3M9IGtleTogMWYwYTI3NjMt NWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkIHZhbHVlOiBWTQosIHNoYXJlZExvY2tzPSBdCjIw MTMtMTEtMDMgMTE6NTY6MDMsNjE3IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJv a2VyLklzVm1EdXJpbmdJbml0aWF0aW5nVkRTQ29tbWFuZF0gKGFqcC0tMTI3LjAuMC4xLTg3MDIt MykgWzM2N2YzNGVdIFNUQVJULCBJc1ZtRHVyaW5nSW5pdGlhdGluZ1ZEU0NvbW1hbmQoIHZtSWQg PSAxZjBhMjc2My01YzQwLTRmYTMtYTUxYy1lZDk4Mjc2YjhlNmQpLCBsb2cgaWQ6IGIwYWM2NTcK MjAxMy0xMS0wMyAxMTo1NjowMyw2MTggSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNi cm9rZXIuSXNWbUR1cmluZ0luaXRpYXRpbmdWRFNDb21tYW5kXSAoYWpwLS0xMjcuMC4wLjEtODcw Mi0zKSBbMzY3ZjM0ZV0gRklOSVNILCBJc1ZtRHVyaW5nSW5pdGlhdGluZ1ZEU0NvbW1hbmQsIHJl dHVybjogZmFsc2UsIGxvZyBpZDogYjBhYzY1NwoyMDEzLTExLTAzIDExOjU2OjAzLDY2MiBJTkZP ICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5SdW5WbUNvbW1hbmRdIChwb29sLTYtdGhyZWFk LTQ4KSBbMzY3ZjM0ZV0gUnVubmluZyBjb21tYW5kOiBSdW5WbUNvbW1hbmQgaW50ZXJuYWw6IGZh bHNlLiBFbnRpdGllcyBhZmZlY3RlZCA6ICBJRDogMWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5 ODI3NmI4ZTZkIFR5cGU6IFZNCjIwMTMtMTEtMDMgMTE6NTY6MDMsNzIxIElORk8gIFtvcmcub3Zp cnQuZW5naW5lLmNvcmUudmRzYnJva2VyLmlyc2Jyb2tlci5Jc29QcmVmaXhWRFNDb21tYW5kXSAo cG9vbC02LXRocmVhZC00OCkgWzM2N2YzNGVdIFNUQVJULCBJc29QcmVmaXhWRFNDb21tYW5kKCBz dG9yYWdlUG9vbElkID0gOWI0NzYyNzQtN2MxYy00NzYyLThjYjQtNjk5YzI3MjliMTUyLCBpZ25v cmVGYWlsb3ZlckxpbWl0ID0gZmFsc2UpLCBsb2cgaWQ6IDMyNzU2ZDM3CjIwMTMtMTEtMDMgMTE6 NTY6MDMsNzIyIElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLmlyc2Jyb2tl ci5Jc29QcmVmaXhWRFNDb21tYW5kXSAocG9vbC02LXRocmVhZC00OCkgWzM2N2YzNGVdIEZJTklT SCwgSXNvUHJlZml4VkRTQ29tbWFuZCwgcmV0dXJuOiAvcmhldi9kYXRhLWNlbnRlci9tbnQvbGl2 ZWNkLmxvY2FsZG9tYWluOl92YXJfbGliX2V4cG9ydHNfaXNvLzliYTA0N2YwLTE4ODMtNGY0NS1i MDIyLWJiZjZhZmJkNTc4NC9pbWFnZXMvMTExMTExMTEtMTExMS0xMTExLTExMTEtMTExMTExMTEx MTExLCBsb2cgaWQ6IDMyNzU2ZDM3CjIwMTMtMTEtMDMgMTE6NTY6MDMsNzMwIElORk8gIFtvcmcu b3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLkNyZWF0ZVZtVkRTQ29tbWFuZF0gKHBvb2wtNi10 aHJlYWQtNDgpIFszNjdmMzRlXSBTVEFSVCwgQ3JlYXRlVm1WRFNDb21tYW5kKEhvc3ROYW1lID0g bG9jYWxfaG9zdCwgSG9zdElkID0gZWEzZGMyYTgtNzBjMS00OTIxLTlhZDUtMjdkMWU5YzIxNzA1 LCB2bUlkPTFmMGEyNzYzLTVjNDAtNGZhMy1hNTFjLWVkOTgyNzZiOGU2ZCwgdm09Vk0gW2xvY2Fs X3ZtXSksIGxvZyBpZDogMjQxYjVhNmMKMjAxMy0xMS0wMyAxMTo1NjowMyw3MzcgSU5GTyAgW29y Zy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIudmRzYnJva2VyLkNyZWF0ZVZEU0NvbW1hbmRd IChwb29sLTYtdGhyZWFkLTQ4KSBbMzY3ZjM0ZV0gU1RBUlQsIENyZWF0ZVZEU0NvbW1hbmQoSG9z dE5hbWUgPSBsb2NhbF9ob3N0LCBIb3N0SWQgPSBlYTNkYzJhOC03MGMxLTQ5MjEtOWFkNS0yN2Qx ZTljMjE3MDUsIHZtSWQ9MWYwYTI3NjMtNWM0MC00ZmEzLWE1MWMtZWQ5ODI3NmI4ZTZkLCB2bT1W TSBbbG9jYWxfdm1dKSwgbG9nIGlkOiBjOTM5NGNmCjIwMTMtMTEtMDMgMTE6NTY6MDMsNzgxIElO Rk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5DcmVhdGVWRFND b21tYW5kXSAocG9vbC02LXRocmVhZC00OCkgWzM2N2YzNGVdIG9yZy5vdmlydC5lbmdpbmUuY29y ZS52ZHNicm9rZXIudmRzYnJva2VyLkNyZWF0ZVZEU0NvbW1hbmQgc3BpY2VTc2xDaXBoZXJTdWl0 ZT1ERUZBVUxULG1lbVNpemU9MTAyNCxrdm1FbmFibGU9dHJ1ZSxzbXA9MSx2bVR5cGU9a3ZtLGVt dWxhdGVkTWFjaGluZT1yaGVsNi40LjAsa2V5Ym9hcmRMYXlvdXQ9ZW4tdXMsbWVtR3VhcmFudGVl ZFNpemU9MTAyNCxuaWNlPTAsZGlzcGxheT1xeGwsc21hcnRjYXJkRW5hYmxlPWZhbHNlLHNtcENv cmVzUGVyU29ja2V0PTEsc3BpY2VTZWN1cmVDaGFubmVscz1zbWFpbixzaW5wdXRzLHNjdXJzb3Is c3BsYXliYWNrLHNyZWNvcmQsc2Rpc3BsYXksc3VzYnJlZGlyLHNzbWFydGNhcmQsdGltZU9mZnNl dD0wLHRyYW5zcGFyZW50SHVnZVBhZ2VzPXRydWUsdm1JZD0xZjBhMjc2My01YzQwLTRmYTMtYTUx Yy1lZDk4Mjc2YjhlNmQsZGV2aWNlcz1bTGphdmEudXRpbC5IYXNoTWFwO0A2N2MyY2FiOSxhY3Bp RW5hYmxlPXRydWUsdm1OYW1lPWxvY2FsX3ZtLGNwdVR5cGU9UGVucnluLGN1c3RvbT17fQoyMDEz LTExLTAzIDExOjU2OjAzLDc4MyBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tl ci52ZHNicm9rZXIuQ3JlYXRlVkRTQ29tbWFuZF0gKHBvb2wtNi10aHJlYWQtNDgpIFszNjdmMzRl XSBGSU5JU0gsIENyZWF0ZVZEU0NvbW1hbmQsIGxvZyBpZDogYzkzOTRjZgoyMDEzLTExLTAzIDEx OjU2OjAzLDc4OCBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci5DcmVhdGVW bVZEU0NvbW1hbmRdIChwb29sLTYtdGhyZWFkLTQ4KSBbMzY3ZjM0ZV0gRklOSVNILCBDcmVhdGVW bVZEU0NvbW1hbmQsIHJldHVybjogV2FpdEZvckxhdW5jaCwgbG9nIGlkOiAyNDFiNWE2YwoyMDEz LTExLTAzIDExOjU2OjAzLDc4OSBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5SdW5W bUNvbW1hbmRdIChwb29sLTYtdGhyZWFkLTQ4KSBbMzY3ZjM0ZV0gTG9jayBmcmVlZCB0byBvYmpl Y3QgRW5naW5lTG9jayBbZXhjbHVzaXZlTG9ja3M9IGtleTogMWYwYTI3NjMtNWM0MC00ZmEzLWE1 MWMtZWQ5ODI3NmI4ZTZkIHZhbHVlOiBWTQosIHNoYXJlZExvY2tzPSBdCjIwMTMtMTEtMDMgMTE6 NTY6MDMsODEzIElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUuZGFsLmRiYnJva2VyLmF1ZGl0 bG9naGFuZGxpbmcuQXVkaXRMb2dEaXJlY3Rvcl0gKHBvb2wtNi10aHJlYWQtNDgpIFszNjdmMzRl XSBDb3JyZWxhdGlvbiBJRDogMzY3ZjM0ZSwgSm9iIElEOiAyZmFmMDQ4ZS1lMTc2LTQxZTItODYx OC1iNmVjYzE0ZTA4YjgsIENhbGwgU3RhY2s6IG51bGwsIEN1c3RvbSBFdmVudCBJRDogLTEsIE1l c3NhZ2U6IFZNIGxvY2FsX3ZtIHdhcyBzdGFydGVkIGJ5IGFkbWluQGludGVybmFsIChIb3N0OiBs b2NhbF9ob3N0KS4KCg== ------=_Part_18229105_1410910980.1383498088935--

2 1

[Engine-devel] [oVirt jenkins] Weekly report on open tasks for ovirt-engine
by Jenkins ci oVirt Server 01 Nov '13

01 Nov '13

------=_Part_142_735046232.1383264254716 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit <html><head></head><body><b>Files scanned: '**/*.java, **/*.py'. </b><br /> <b>Strings searched: FIXME | TODO | @deprecated </b> <br /><br /> Report: http://jenkins.ovirt.org/job/ovirt_engine_scan_open_tasks/13/tasksResult/?</body></html> ------=_Part_142_735046232.1383264254716--

1 0