April 2014 - Devel - oVirt List Archives

[Devel] Proposing Yedidyah Bar David as oVirt Hosted Engine Setup maintainer
by Sandro Bonazzola 14 Jan '15

14 Jan '15

Hi, I would like to propose Yedidyah Bar David as oVirt Hosted Engine Setup co-maintainer. Yedidyah contributed to oVirt Hosted Engine Setup since early design phase and contributed dozens of patches. Your response would be appreciated. Thanks in advance. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

7 8

new ovirt-deps repo package
by Sven Kieske 19 May '14

19 May '14

Hi, I got a question regarding the newly introduced deps package which installs epel etc: https://bugzilla.redhat.com/show_bug.cgi?id=1082013 How does this handle already installed EPEL repositorys? would this conflict somehow? Looking at the code at: http://gerrit.ovirt.org/#/c/26330/8/ovirt-el-deps.repo you restrict the packages to those needed by ovirt. Maybe I don't know yum internals enough, but doesn't this break if other packages from epel are already installed? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

2 1

Help debugging engine.log
by Sandro Bonazzola 12 May '14

12 May '14

the following lines appear after adding the first host to an engine running inside Hosted Engine VM. Can anybody tell what the following lines are meaning? 2014-04-18 17:21:57,223 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (pool-4-thread-5) [751509c7] FINISH, SetVdsStatusVDSCommand, log id: 6bb07f05 2014-04-18 17:21:57,223 INFO [org.ovirt.engine.core.bll.InstallVdsCommand] (pool-4-thread-5) [751509c7] After Installation host hosted_engine_1, VDS 2014-04-18 17:21:57,243 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (pool-4-thread-5) [751509c7] Correlation ID: 751509c7, Job ID: c7abd67c-5655-4ea8-8226-c51eda9c9675, Call Stac k: null, Custom Event ID: -1, Message: Host hosted_engine_1 installed 2014-04-18 17:21:57,255 INFO [org.ovirt.engine.core.bll.InstallVdsCommand] (pool-4-thread-5) [751509c7] Lock freed to object EngineLock [exclusiveLocks= key: f609e5f8-1676-4e87-98ec-9477afc27557 value: VDS , sharedLocks= ] 2014-04-18 17:21:58,764 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-3) START, GetHardwareInfoVDSCommand(HostName = hosted_engine_1, HostId = f609e5f 8-1676-4e87-98ec-9477afc27557, vds=Host[hosted_engine_1]), log id: 496d80d8 2014-04-18 17:21:58,834 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-3) FINISH, GetHardwareInfoVDSCommand, log id: 496d80d8 2014-04-18 17:21:58,944 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-3) START, GetHardwareInfoVDSCommand(HostName = hosted_engine_1, HostId = f609e5f8-1676-4e87-98ec-9477afc27557, vds=Host[hosted_engine_1]), log id: 36957393 2014-04-18 17:21:58,971 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-3) FINISH, GetHardwareInfoVDSCommand, log id: 36957393 2014-04-18 17:21:58,989 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-3) Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: State was set to Up for host hosted_engine_1. 2014-04-18 17:21:59,058 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.FullListVdsCommand] (DefaultQuartzScheduler_Worker-3) START, FullListVdsCommand(HostName = hosted_engine_1, HostId = f609e5f8-1676-4e87-98ec-9477afc27557, vds=Host[hosted_engine_1], vmIds=[950f8a3a-82af-478e-8f99-9cd0556b9cfc]), log id: 16b792bc 2014-04-18 17:21:59,095 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.FullListVdsCommand] (DefaultQuartzScheduler_Worker-3) FINISH, FullListVdsCommand, return: [Ljava.util.HashMap;@3a6e1bc2, log id: 16b792bc 2014-04-18 17:21:59,096 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-3) Importing VM HostedEngine as HostedEngine, as it is running on the on Host, but does not exist in the engine. 2014-04-18 17:21:59,122 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-3) VDS::UpdateVmRunTimeInfo Error: found VM on a VDS that is not in the database! 2014-04-18 17:21:59,137 INFO [org.ovirt.engine.core.bll.InitVdsOnUpCommand] (DefaultQuartzScheduler_Worker-3) [3a5f7d19] Running command: InitVdsOnUpCommand internal: true. Entities affected : ID: 5849b030-626e-47cb-ad90-3ce782d831b3 Type: StoragePool 2014-04-18 17:21:59,144 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SetMOMPolicyParametersVDSCommand] (DefaultQuartzScheduler_Worker-3) [3a5f7d19] START, SetMOMPolicyParametersVDSCommand(HostName = hosted_engine_1, HostId = f609e5f8-1676-4e87-98ec-9477afc27557), log id: 36c8962e 2014-04-18 17:21:59,223 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SetMOMPolicyParametersVDSCommand] (DefaultQuartzScheduler_Worker-3) [3a5f7d19] FINISH, SetMOMPolicyParametersVDSCommand, log id: 36c8962e 2014-04-18 17:21:59,228 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-3) [3a5f7d19] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: Failed to verify Power Management configuration for Host hosted_engine_1. 2014-04-18 17:21:59,389 INFO [org.ovirt.engine.core.bll.AddVmFromScratchCommand] (DefaultQuartzScheduler_Worker-3) [266af7f3] Lock Acquired to object EngineLock [exclusiveLocks= key: HostedEngine value: VM_NAME , sharedLocks= ] 2014-04-18 17:21:59,453 INFO [org.ovirt.engine.core.bll.AddVmFromScratchCommand] (DefaultQuartzScheduler_Worker-3) [266af7f3] Running command: AddVmFromScratchCommand internal: true. Entities affected : ID: 99408929-82cf-4dc7-a532-9d998063fa95 Type: VdsGroups 2014-04-18 17:21:59,707 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-3) [266af7f3] Correlation ID: 266af7f3, Job ID: 2c46a619-bc01-4b85-96bd-d3fc5e073901, Call Stack: null, Custom Event ID: -1, Message: VM HostedEngine was created by <UNKNOWN>. 2014-04-18 17:21:59,714 INFO [org.ovirt.engine.core.bll.AddVmFromScratchCommand] (DefaultQuartzScheduler_Worker-3) [266af7f3] Lock freed to object EngineLock [exclusiveLocks= key: HostedEngine value: VM_NAME , sharedLocks= ] 2014-04-18 17:21:59,718 INFO [org.ovirt.engine.core.bll.HandleVdsCpuFlagsOrClusterChangedCommand] (DefaultQuartzScheduler_Worker-3) [5e0dc4d1] Running command: HandleVdsCpuFlagsOrClusterChangedCommand internal: true. Entities affected : ID: f609e5f8-1676-4e87-98ec-9477afc27557 Type: VDS 2014-04-18 17:21:59,766 INFO [org.ovirt.engine.core.bll.UpdateVdsGroupCommand] (DefaultQuartzScheduler_Worker-3) [32fd282a] Running command: UpdateVdsGroupCommand internal: true. Entities affected : ID: 99408929-82cf-4dc7-a532-9d998063fa95 Type: VdsGroups 2014-04-18 17:22:00,015 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-3) [32fd282a] Correlation ID: 32fd282a, Call Stack: null, Custom Event ID: -1, Message: Host cluster Default was updated by system 2014-04-18 17:22:00,032 INFO [org.ovirt.engine.core.bll.HandleVdsVersionCommand] (DefaultQuartzScheduler_Worker-3) [4f38fad3] Running command: HandleVdsVersionCommand internal: true. Entities affected : ID: f609e5f8-1676-4e87-98ec-9477afc27557 Type: VDS 2014-04-18 17:22:03,100 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.FullListVdsCommand] (DefaultQuartzScheduler_Worker-6) START, FullListVdsCommand(HostName = hosted_engine_1, HostId = f609e5f8-1676-4e87-98ec-9477afc27557, vds=Host[hosted_engine_1], vmIds=[950f8a3a-82af-478e-8f99-9cd0556b9cfc]), log id: 4148c04c 2014-04-18 17:22:03,129 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.FullListVdsCommand] (DefaultQuartzScheduler_Worker-6) FINISH, FullListVdsCommand, return: [Ljava.util.HashMap;@5f864ed0, log id: 4148c04c 2014-04-18 17:22:03,131 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-6) Received a console Device without an address when processing VM 950f8a3a-82af-478e-8f99-9cd0556b9cfc devices, skipping device: {alias=console0, specParams={}, device=console, type=console, deviceId=c627f372-2893-4b79-b534-f51c86374d1b} 2014-04-18 17:22:03,131 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-6) Received a memballoon Device without an address when processing VM 950f8a3a-82af-478e-8f99-9cd0556b9cfc devices, skipping device: {alias=balloon0, specParams={model=none}, device=memballoon, type=balloon} 2014-04-18 17:22:03,132 ERROR [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-6) Empty or NULL values were passed for a VM 950f8a3a-82af-478e-8f99-9cd0556b9cfc device, Device is skipped 2014-04-18 17:53:16,713 INFO [org.ovirt.engine.core.bll.LogoutUserCommand] (ajp-/127.0.0.1:8702-5) [3829e38e] Running command: LogoutUserCommand internal: false. 2014-04-18 17:53:16,725 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp-/127.0.0.1:8702-5) [3829e38e] Correlation ID: 3829e38e, Call Stack: null, Custom Event ID: -1, Message: User admin@internal logged out. 2014-04-18 17:54:28,145 INFO [org.ovirt.engine.core.bll.LoginAdminUserCommand] (ajp-/127.0.0.1:8702-4) Running command: LoginAdminUserCommand internal: false. 2014-04-18 17:54:28,149 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp-/127.0.0.1:8702-4) Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: User admin@internal logged in. 2014-04-18 17:54:28,207 INFO [org.ovirt.engine.core.bll.LoginUserCommand] (ajp-/127.0.0.1:8702-8) Running command: LoginUserCommand internal: false. 2014-04-18 17:54:28,212 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp-/127.0.0.1:8702-8) Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: User admin@internal logged in. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

3 6

building ovirt-shell on debian
by Sven Kieske 12 May '14

12 May '14

Hi, I'm currently writing a little howto for people who use debian based systems so they can benefit from ovirt-shell. after installing all dependencies easy_install ovirt-shell seemed to work. However I got one error which I'd like to get fixed: Building against libxml2/libxslt in the following directory: /usr/lib /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'bugtrack_url' warnings.warn(msg) Adding lxml 3.3.4 to easy-install.pth file Maybe someone could assist me with that? In general it would be cool especially for development tools like sdks and the cli if they are available prepackaged not just for RHEL derivatives as it would pretty much speed up the distribution of oVirt itself and attract more devs if they can use their environment without needing to setup fedora/centos. I'll therefore try to forge a deb package in my very little spare time. any help would be appreciated. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

3 3

Custom Properties code duplication
by Lior Vernia 08 May '14

08 May '14

Hello, While adding network custom properties towards oVirt 3.5, I got to take a good look at the custom properties code in the backend and frontend. It seems to me like there's a lot of code duplication, and I would like to suggest the following refactoring: 1. Remove dependencies on Pattern/Matcher and ApacheCommons methods from *CustomPropertiesUtils.java, to make them compilable with GWT, and move these utilities to the common package. The usage of the said methods is minimal and could easily be replaced with String methods, etc. 2. Modify KeyValueModel to delegate to the common utilities instead of duplicating code, e.g. for validation. 3. Move some validation, which is relevant to all custom properties (e.g. duplicate keys), from specific utils (e.g. VmPropertiesUtils) up to the shared CustomPropertiesUtils. 4. Optionally change the implementation of custom properties members in entities (e.g. VM) from String to Map<String, String>, which would obviate the need for different conversion methods between String/Map - (de)serialization would only be required in DB interaction. The main argument against this would be that the frontend is to be moved over the REST, and might not be written in Java much longer anyway. However, to my understanding, there's some time until these changes take effect. And even if the frontend is to be written in JavaScript, at least initially the existing frontend code will have to still be used somehow (e.g. auto-translated to JavaScript). That is to say, this refactoring might still be beneficial for the not-so-short term. Before going through with this, I wanted to ask for your thoughts and to hear any specific objections to the proposed changes. Yours, Lior.

4 9

commons-collections v4.0
by Yevgeny Zaspitsky 08 May '14

08 May '14

Hi All, I'd like to add the new version (4.0) of Apache commons-collections library to the dependencies of the project (we use 3.1 currently). The new version uses the generics features of Java 5 so that make the code more type safe. You can find the full list of changes on https://commons.apache.org/proper/commons-collections/release_4_0.html. The new API is based on the original but it isn't fully compatible with it. So in order to make the migration to the new API easier, the package has been changed to org.apache.commons.collections4. That allows having both version of the library in the classpath at the starting point and move (refactor) towards the new version gradually. I have couple of questions regarding the new dependency: 1. Is there anything that could prevent adding the new dependency? 2. I did the change (http://gerrit.ovirt.org/26745) The unit tests that use the new dependency pass locally and in Jenkins environments. However when I try to run a code that is dependent on the newly added library NoClassDefFoundError being thrown. Also I can't find commons-collections4 jar under the installation directory. I use "make clean install-dev" command for building. Please advise. Best regards, ____________________ Yevgeny Zaspitsky Senior Software Engineer Red Hat

4 7

Fwd: Re: Mass bug: packages should not auto-enable systemd units
by Vinzenz Feenstra 07 May '14

07 May '14

---------- Forwarded message ---------- From: "Andrew Lutomirski" <luto(a)mit.edu> Date: Apr 30, 2014 7:46 PM Subject: Re: Mass bug: packages should not auto-enable systemd units To: <devel-announce(a)lists.fedoraproject.org> Cc: Due to some confusion around how alternatives worked, I screwed up the list of packages here. I've updated it below. I'll give it a few more days before filing the actual bugs. On Wed, Apr 23, 2014 at 4:59 PM, Andrew Lutomirski <luto(a)mit.edu> wrote: > Hi everyone- > > This is a notice in accordance with the mass bug filing procedure. > > A number of packages install systemd units and enable them > automatically. They should not. Please update these packages to use the > macroized scriptlet > (https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd) > > If your package has an exception from FESCo permitting it to enable > itself, please make sure that the service in question is listed in the > appropriate preset file. > > There is a general exception described here: > > https://fedoraproject.org/wiki/Starting_services_by_default > > If your package falls under the general exception, then it is possible > that no change is required. Nevertheless, if you are relying on the > exception, please make sure that your rpm scripts are sensible. The > exception is: > > In addition, any service which does not remain persistent on the > system (aka, it "runs once then goes away"), does not listen to > incoming connections during initialization, and does not require > configuration to be functional may be enabled by default (but is not > required to do so). An example of "runs once then goes away" service > is iptables. > > Given that this issue can affect Fedora 20 users who install your > package as a dependency, these bugs should be fixed in Fedora 20 and > Rawhide. > > The tracker bug is here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1090684 > > I created it early because three of the bugs are pre-existing. Next > week, I'll file bugs against the packages below. If you fix your > package in the mean time, please let me know. > > After three weeks, provenpackagers may step in and fix these issues. > abrt acpid aeolus-audrey-agent aeolus-configserver audit avahi bluez bootchart cherokee cloud-init deltacloud-core dmapd dnssec-trigger glusterfs gnome-initial-setup gpsd ipmiutil iptables kexec-tools libstoragemgmt libvirt lttng-tools monit NetworkManager nfs-utils nss-pam-ldapd olpc-kbdshim olpc-powerd openct pcsc-lite qemu qpid-cpp rootfs-resize rpcbind sendmail soundmodem spacenavd subscription-manager supervisor systemd targetcli util-linux vdsm xen --Andy _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

3 3

Re: [ovirt-devel] Change in ovirt-engine[master]: restapi: NUMA feature restful API support
by Liao, Chuan (Jason Liao, HPservers-Core-OE-PSC) 06 May '14

06 May '14

--_002_B63C858E777679458338A30A991BB52401624855G1W3780americas_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldoZW4gd2UgZmluaXNoIGFsbCB0aGUgcmVzdGZ1bCBBUEkgY29kZSBmb3IgTlVNQSBm ZWF0dXJlIGFuZCB0ZXN0IGl0Lg0KDQpXZSBtZXQgb25lIHByb2JsZW0gd2hpY2ggaXMgaGFyZCB0 byBkZWJ1ZywgYXMgYXR0YWNobWVudC4NCg0KQ291bGQgeW91IGhlbHAgdXMgdG8gcmV2aWV3IG91 ciBjb2RlIG9yIGdpdmUgdXMgc29tZSBzdWdnZXN0aW9uIHRvIGRlYnVnIHRoaXMgcHJvYmxlbSA/ DQpUaGUgcGF0Y2ggc2V0IGxpbms6DQpodHRwOi8vZ2Vycml0Lm92aXJ0Lm9yZy8yNjk0Mw0KDQpU aGFuayB5b3UgdmVyeSBtdWNoLg0KDQpCZXN0IFJlZ2FyZHMsDQpKYXNvbiBMaWFvDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogYXV0b21hdGlvbkBvdmlydC5vcmcgW21h aWx0bzphdXRvbWF0aW9uQG92aXJ0Lm9yZ10NCj4gU2VudDogMjAxNOW5tDTmnIgzMOaXpSAxOTo1 Ng0KPiBUbzogTGlhbywgQ2h1YW4gKEphc29uIExpYW8sIEhQc2VydmVycy1Db3JlLU9FLVBTQykN Cj4gQ2M6IEp1YW4gSGVybmFuZGV6OyBHaWxhZCBDaGFwbGlrOyBBbGV4YW5kZXIgV2Vscw0KPiBT dWJqZWN0OiBDaGFuZ2UgaW4gb3ZpcnQtZW5naW5lW21hc3Rlcl06IHJlc3RhcGk6IE5VTUEgZmVh dHVyZSByZXN0ZnVsIEFQSSBzdXBwb3J0DQo+IA0KPiBhdXRvbWF0aW9uQG92aXJ0Lm9yZyBoYXMg cG9zdGVkIGNvbW1lbnRzIG9uIHRoaXMgY2hhbmdlLg0KPiANCj4gQ2hhbmdlIHN1YmplY3Q6IHJl c3RhcGk6IE5VTUEgZmVhdHVyZSByZXN0ZnVsIEFQSQ0KPiBzdXBwb3J0IC4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4N Cj4gDQo+IA0KPiBQYXRjaCBTZXQgMjoNCj4gDQo+ICogIzEwNjkzMDM6OlVwZGF0ZSB0cmFja2Vy OiBPSw0KPiAqIEJ1Zy1Vcmw6IElHTk9SRSwgbm90IGluIGEgbW9uaXRvcmVkIGJyYW5jaCAob3Zp cnQtZW5naW5lLTMuNA0KPiAqIENoZWNrIG1lcmdlZCB0byBwcmV2aW91czogSUdOT1JFLCBOb3Qg aW4gc3RhYmxlIGJyYW5jaCAoWydvdmlydC1lbmdpbmUtMy40JywNCj4gJ292aXJ0LWVuZ2luZS0z LjMnLCAnb3ZpcnQtZW5naW5lLTMuNC4wJywgJ292aXJ0LWVuZ2luZS0zLjMuNCcsICdvdmlydC1l bmdpbmUtMy4zLjMnLA0KPiAnb3ZpcnQtZW5naW5lLTMuMy4yJywgJ292aXJ0LWVuZ2luZS0zLjMu MSddKQ0KPiANCj4gLS0NCj4gVG8gdmlldywgdmlzaXQgaHR0cDovL2dlcnJpdC5vdmlydC5vcmcv MjY5NDMgVG8gdW5zdWJzY3JpYmUsIHZpc2l0DQo+IGh0dHA6Ly9nZXJyaXQub3ZpcnQub3JnL3Nl dHRpbmdzDQo+IA0KPiBHZXJyaXQtTWVzc2FnZVR5cGU6IGNvbW1lbnQNCj4gR2Vycml0LUNoYW5n ZS1JZDogSTcyZWQ0YjE2YzIyMGRlY2JmNjQwZjc0YzRhYWRmZmU0MjNhZmMyOTANCj4gR2Vycml0 LVBhdGNoU2V0OiAyDQo+IEdlcnJpdC1Qcm9qZWN0OiBvdmlydC1lbmdpbmUNCj4gR2Vycml0LUJy YW5jaDogbWFzdGVyDQo+IEdlcnJpdC1Pd25lcjogSmFzb24gTGlhbyA8Y2h1YW4ubGlhb0BocC5j b20+DQo+IEdlcnJpdC1SZXZpZXdlcjogQWxleGFuZGVyIFdlbHMgPGF3ZWxzQHJlZGhhdC5jb20+ DQo+IEdlcnJpdC1SZXZpZXdlcjogR2lsYWQgQ2hhcGxpayA8Z2NoYXBsaWtAcmVkaGF0LmNvbT4N Cj4gR2Vycml0LVJldmlld2VyOiBKdWFuIEhlcm5hbmRleiA8anVhbi5oZXJuYW5kZXpAcmVkaGF0 LmNvbT4NCj4gR2Vycml0LVJldmlld2VyOiBhdXRvbWF0aW9uQG92aXJ0Lm9yZw0KPiBHZXJyaXQt UmV2aWV3ZXI6IG9WaXJ0IEplbmtpbnMgQ0kgU2VydmVyDQo+IEdlcnJpdC1IYXNDb21tZW50czog Tm8NCg== --_002_B63C858E777679458338A30A991BB52401624855G1W3780americas_ Content-Type: application/octet-stream; name="server.log" Content-Description: server.log Content-Disposition: attachment; filename="server.log"; size=12863; creation-date="Wed, 30 Apr 2014 11:59:42 GMT"; modification-date="Wed, 30 Apr 2014 12:00:09 GMT" Content-Transfer-Encoding: base64 MjAxNC0wNC0zMCAwNDo0NzowMSwwMjggSU5GTyAgW29yZy5qYm9zcy53ZWJdIChNU0Mgc2Vydmlj ZSB0aHJlYWQgMS0xKSBKQkFTMDE4MjEwOiBSZWdpc3RlcmluZyB3ZWIgY29udGV4dDogL292aXJ0 LWVuZ2luZQ0KMjAxNC0wNC0zMCAwNDo0NzowMSwwMjkgSU5GTyAgW29yZy5qYm9zcy53ZWJdIChN U0Mgc2VydmljZSB0aHJlYWQgMS00KSBKQkFTMDE4MjEwOiBSZWdpc3RlcmluZyB3ZWIgY29udGV4 dDogL292aXJ0LWVuZ2luZS93ZWJhZG1pbg0KMjAxNC0wNC0zMCAwNDo0NzowMSwwMzAgSU5GTyAg W29yZy5qYm9zcy53ZWJdIChNU0Mgc2VydmljZSB0aHJlYWQgMS03KSBKQkFTMDE4MjEwOiBSZWdp c3RlcmluZyB3ZWIgY29udGV4dDogL292aXJ0LWVuZ2luZS9kb2NzDQoyMDE0LTA0LTMwIDA0OjQ3 OjAxLDAzMSBJTkZPICBbb3JnLmpib3NzLndlYl0gKE1TQyBzZXJ2aWNlIHRocmVhZCAxLTUpIEpC QVMwMTgyMTA6IFJlZ2lzdGVyaW5nIHdlYiBjb250ZXh0OiAvb3ZpcnQtZW5naW5lL3VzZXJwb3J0 YWwNCjIwMTQtMDQtMzAgMDQ6NDc6MDEsMDg2IElORk8gIFtvcmcuc3ByaW5nZnJhbWV3b3JrLmJl YW5zLmZhY3RvcnkueG1sLlhtbEJlYW5EZWZpbml0aW9uUmVhZGVyXSAoTVNDIHNlcnZpY2UgdGhy ZWFkIDEtMikgTG9hZGluZyBYTUwgYmVhbiBkZWZpbml0aW9ucyBmcm9tIGNsYXNzIHBhdGggcmVz b3VyY2UgW29yZy9zcHJpbmdmcmFtZXdvcmsvamRiYy9zdXBwb3J0L3NxbC1lcnJvci1jb2Rlcy54 bWxdDQoyMDE0LTA0LTMwIDA0OjQ3OjAxLDI0NCBJTkZPICBbb3JnLnNwcmluZ2ZyYW1ld29yay5q ZGJjLnN1cHBvcnQuU1FMRXJyb3JDb2Rlc0ZhY3RvcnldIChNU0Mgc2VydmljZSB0aHJlYWQgMS0y KSBTUUxFcnJvckNvZGVzIGxvYWRlZDogW0RCMiwgRGVyYnksIEgyLCBIU1FMLCBJbmZvcm1peCwg TVMtU1FMLCBNeVNRTCwgT3JhY2xlLCBQb3N0Z3JlU1FMLCBTeWJhc2VdDQoyMDE0LTA0LTMwIDA0 OjQ3OjAyLDQ5NyBJTkZPICBbb3JnLmpib3NzLmFzXSAoTVNDIHNlcnZpY2UgdGhyZWFkIDEtNykg SkJBUzAxNTg3NDogSkJvc3MgQVMgNy4xLjEuRmluYWwgIkJyb250ZXMiIHN0YXJ0ZWQgaW4gNjkw MG1zIC0gU3RhcnRlZCA2ODMgb2YgNzI5IHNlcnZpY2VzICg0NSBzZXJ2aWNlcyBhcmUgcGFzc2l2 ZSBvciBvbi1kZW1hbmQpDQoyMDE0LTA0LTMwIDA0OjQ3OjAyLDU2MyBJTkZPICBbb3JnLmpib3Nz LmFzLnNlcnZlcl0gKERlcGxveW1lbnRTY2FubmVyLXRocmVhZHMgLSAyKSBKQkFTMDE4NTU5OiBE ZXBsb3llZCAiZW5naW5lLmVhciINCjIwMTQtMDQtMzAgMDQ6NDc6MDYsNDg1IElORk8gIFtvcmcu aGliZXJuYXRlLnZhbGlkYXRvci51dGlsLlZlcnNpb25dIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVy X1dvcmtlci02KSBIaWJlcm5hdGUgVmFsaWRhdG9yIDQuMi4wLkZpbmFsDQoyMDE0LTA0LTMwIDA0 OjQ3OjE2LDc3NiBJTkZPICBbb3JnLmpib3NzLnJlc3RlYXN5LnNwaS5SZXN0ZWFzeURlcGxveW1l bnRdIChodHRwLS0wLjAuMC4wLTgwODAtMSkgRGVwbG95aW5nIGphdmF4LndzLnJzLmNvcmUuQXBw bGljYXRpb246IGNsYXNzIG9yZy5vdmlydC5lbmdpbmUuYXBpLnJlc3RhcGkuQmFja2VuZEFwcGxp Y2F0aW9uDQoyMDE0LTA0LTMwIDA0OjQ3OjE2LDc3NyBXQVJOICBbb3JnLmpib3NzLnJlc3RlYXN5 LnNwaS5SZXN0ZWFzeURlcGxveW1lbnRdIChodHRwLS0wLjAuMC4wLTgwODAtMSkgQXBwbGljYXRp b24uZ2V0U2luZ2xldG9ucygpIHJldHVybmVkIHVua25vd24gY2xhc3MgdHlwZTogb3JnLm92aXJ0 LmVuZ2luZS5hcGkucmVzdGFwaS51dGlsLlZtSGVscGVyDQoyMDE0LTA0LTMwIDA0OjQ3OjE2LDc3 OCBJTkZPICBbb3JnLmpib3NzLnJlc3RlYXN5LnNwaS5SZXN0ZWFzeURlcGxveW1lbnRdIChodHRw LS0wLjAuMC4wLTgwODAtMSkgQWRkaW5nIHNpbmdsZXRvbiByZXNvdXJjZSBvcmcub3ZpcnQuZW5n aW5lLmFwaS5yZXN0YXBpLnJlc291cmNlLkJhY2tlbmRKb2JzUmVzb3VyY2UgZnJvbSBBcHBsaWNh dGlvbiBqYXZheC53cy5ycy5jb3JlLkFwcGxpY2F0aW9uDQoyMDE0LTA0LTMwIDA0OjQ3OjE2LDc3 OSBJTkZPICBbb3JnLmpib3NzLnJlc3RlYXN5LnNwaS5SZXN0ZWFzeURlcGxveW1lbnRdIChodHRw LS0wLjAuMC4wLTgwODAtMSkgQWRkaW5nIHNpbmdsZXRvbiByZXNvdXJjZSBvcmcub3ZpcnQuZW5n aW5lLmFwaS5yZXN0YXBpLnJlc291cmNlLkJhY2tlbmRVc2Vyc1Jlc291cmNlIGZyb20gQXBwbGlj YXRpb24gamF2YXgud3MucnMuY29yZS5BcHBsaWNhdGlvbg0KMjAxNC0wNC0zMCAwNDo0NzoxNiw3 ODAgSU5GTyAgW29yZy5qYm9zcy5yZXN0ZWFzeS5zcGkuUmVzdGVhc3lEZXBsb3ltZW50XSAoaHR0 cC0tMC4wLjAuMC04MDgwLTEpIEFkZGluZyBzaW5nbGV0b24gcmVzb3VyY2Ugb3JnLm92aXJ0LmVu Z2luZS5hcGkucmVzdGFwaS5yZXNvdXJjZS5CYWNrZW5kVm5pY1Byb2ZpbGVzUmVzb3VyY2UgZnJv bSBBcHBsaWNhdGlvbiBqYXZheC53cy5ycy5jb3JlLkFwcGxpY2F0aW9uDQoyMDE0LTA0LTMwIDA0 OjQ3OjE2LDc4MSBJTkZPICBbb3JnLmpib3NzLnJlc3RlYXN5LnNwaS5SZXN0ZWFzeURlcGxveW1l bnRdIChodHRwLS0wLjAuMC4wLTgwODAtMSkgQWRkaW5nIHNpbmdsZXRvbiByZXNvdXJjZSBvcmcu b3ZpcnQuZW5naW5lLmFwaS5yZXN0YXBpLnJlc291cmNlLkJhY2tlbmRHcm91cHNSZXNvdXJjZSBm cm9tIEFwcGxpY2F0aW9uIGphdmF4LndzLnJzLmNvcmUuQXBwbGljYXRpb24NCjIwMTQtMDQtMzAg MDQ6NDc6MTYsNzgxIElORk8gIFtvcmcuamJvc3MucmVzdGVhc3kuc3BpLlJlc3RlYXN5RGVwbG95 bWVudF0gKGh0dHAtLTAuMC4wLjAtODA4MC0xKSBBZGRpbmcgc2luZ2xldG9uIHJlc291cmNlIG9y Zy5vdmlydC5lbmdpbmUuYXBpLnJlc3RhcGkucmVzb3VyY2UuQmFja2VuZFN0b3JhZ2VEb21haW5z UmVzb3VyY2UgZnJvbSBBcHBsaWNhdGlvbiBqYXZheC53cy5ycy5jb3JlLkFwcGxpY2F0aW9uDQoy MDE0LTA0LTMwIDA0OjQ3OjE2LDc4MiBJTkZPICBbb3JnLmpib3NzLnJlc3RlYXN5LnNwaS5SZXN0 ZWFzeURlcGxveW1lbnRdIChodHRwLS0wLjAuMC4wLTgwODAtMSkgQWRkaW5nIHNpbmdsZXRvbiBy ZXNvdXJjZSBvcmcub3ZpcnQuZW5naW5lLmFwaS5yZXN0YXBpLnJlc291cmNlLkJhY2tlbmRDYXBh YmlsaXRpZXNSZXNvdXJjZSBmcm9tIEFwcGxpY2F0aW9uIGphdmF4LndzLnJzLmNvcmUuQXBwbGlj YXRpb24NCjIwMTQtMDQtMzAgMDQ6NDc6MTYsNzgzIElORk8gIFtvcmcuamJvc3MucmVzdGVhc3ku c3BpLlJlc3RlYXN5RGVwbG95bWVudF0gKGh0dHAtLTAuMC4wLjAtODA4MC0xKSBBZGRpbmcgc2lu Z2xldG9uIHJlc291cmNlIG9yZy5vdmlydC5lbmdpbmUuYXBpLnJlc3RhcGkucmVzb3VyY2UuQmFj a2VuZEhvc3RzUmVzb3VyY2UgZnJvbSBBcHBsaWNhdGlvbiBqYXZheC53cy5ycy5jb3JlLkFwcGxp Y2F0aW9uDQoyMDE0LTA0LTMwIDA0OjQ3OjE2LDc4MyBJTkZPICBbb3JnLmpib3NzLnJlc3RlYXN5 LnNwaS5SZXN0ZWFzeURlcGxveW1lbnRdIChodHRwLS0wLjAuMC4wLTgwODAtMSkgQWRkaW5nIHNp bmdsZXRvbiByZXNvdXJjZSBvcmcub3ZpcnQuZW5naW5lLmFwaS5yZXN0YXBpLnJlc291cmNlLkJh Y2tlbmRCb29rbWFya3NSZXNvdXJjZSBmcm9tIEFwcGxpY2F0aW9uIGphdmF4LndzLnJzLmNvcmUu QXBwbGljYXRpb24NCjIwMTQtMDQtMzAgMDQ6NDc6MTYsNzg0IElORk8gIFtvcmcuamJvc3MucmVz dGVhc3kuc3BpLlJlc3RlYXN5RGVwbG95bWVudF0gKGh0dHAtLTAuMC4wLjAtODA4MC0xKSBBZGRp bmcgc2luZ2xldG9uIHJlc291cmNlIG9yZy5vdmlydC5lbmdpbmUuYXBpLnJlc3RhcGkucmVzb3Vy Y2UuQmFja2VuZERvbWFpbnNSZXNvdXJjZSBmcm9tIEFwcGxpY2F0aW9uIGphdmF4LndzLnJzLmNv cmUuQXBwbGljYXRpb24NCjIwMTQtMDQtMzAgMDQ6NDc6MTYsNzg1IElORk8gIFtvcmcuamJvc3Mu cmVzdGVhc3kuc3BpLlJlc3RlYXN5RGVwbG95bWVudF0gKGh0dHAtLTAuMC4wLjAtODA4MC0xKSBB ZGRpbmcgc2luZ2xldG9uIHJlc291cmNlIG9yZy5vdmlydC5lbmdpbmUuYXBpLnJlc3RhcGkucmVz b3VyY2UuQmFja2VuZFN5c3RlbVBlcm1pc3Npb25zUmVzb3VyY2UgZnJvbSBBcHBsaWNhdGlvbiBq YXZheC53cy5ycy5jb3JlLkFwcGxpY2F0aW9uDQoyMDE0LTA0LTMwIDA0OjQ3OjE2LDc4NSBJTkZP ICBbb3JnLmpib3NzLnJlc3RlYXN5LnNwaS5SZXN0ZWFzeURlcGxveW1lbnRdIChodHRwLS0wLjAu MC4wLTgwODAtMSkgQWRkaW5nIHNpbmdsZXRvbiByZXNvdXJjZSBvcmcub3ZpcnQuZW5naW5lLmFw aS5yZXN0YXBpLnJlc291cmNlLkJhY2tlbmRBcGlSZXNvdXJjZSBmcm9tIEFwcGxpY2F0aW9uIGph dmF4LndzLnJzLmNvcmUuQXBwbGljYXRpb24NCjIwMTQtMDQtMzAgMDQ6NDc6MTYsNzg2IElORk8g IFtvcmcuamJvc3MucmVzdGVhc3kuc3BpLlJlc3RlYXN5RGVwbG95bWVudF0gKGh0dHAtLTAuMC4w LjAtODA4MC0xKSBBZGRpbmcgc2luZ2xldG9uIHJlc291cmNlIG9yZy5vdmlydC5lbmdpbmUuYXBp LnJlc3RhcGkucmVzb3VyY2UuQmFja2VuZFJvbGVzUmVzb3VyY2UgZnJvbSBBcHBsaWNhdGlvbiBq YXZheC53cy5ycy5jb3JlLkFwcGxpY2F0aW9uDQoyMDE0LTA0LTMwIDA0OjQ3OjE2LDc4NyBJTkZP ICBbb3JnLmpib3NzLnJlc3RlYXN5LnNwaS5SZXN0ZWFzeURlcGxveW1lbnRdIChodHRwLS0wLjAu MC4wLTgwODAtMSkgQWRkaW5nIHNpbmdsZXRvbiByZXNvdXJjZSBvcmcub3ZpcnQuZW5naW5lLmFw aS5yZXN0YXBpLnJlc291cmNlLkJhY2tlbmRFdmVudHNSZXNvdXJjZSBmcm9tIEFwcGxpY2F0aW9u IGphdmF4LndzLnJzLmNvcmUuQXBwbGljYXRpb24NCjIwMTQtMDQtMzAgMDQ6NDc6MTYsNzg3IElO Rk8gIFtvcmcuamJvc3MucmVzdGVhc3kuc3BpLlJlc3RlYXN5RGVwbG95bWVudF0gKGh0dHAtLTAu MC4wLjAtODA4MC0xKSBBZGRpbmcgc2luZ2xldG9uIHJlc291cmNlIG9yZy5vdmlydC5lbmdpbmUu YXBpLnJlc3RhcGkucmVzb3VyY2UuQmFja2VuZFZtUG9vbHNSZXNvdXJjZSBmcm9tIEFwcGxpY2F0 aW9uIGphdmF4LndzLnJzLmNvcmUuQXBwbGljYXRpb24NCjIwMTQtMDQtMzAgMDQ6NDc6MTYsNzg4 IElORk8gIFtvcmcuamJvc3MucmVzdGVhc3kuc3BpLlJlc3RlYXN5RGVwbG95bWVudF0gKGh0dHAt LTAuMC4wLjAtODA4MC0xKSBBZGRpbmcgc2luZ2xldG9uIHJlc291cmNlIG9yZy5vdmlydC5lbmdp bmUuYXBpLnJlc3RhcGkucmVzb3VyY2UuQmFja2VuZERhdGFDZW50ZXJzUmVzb3VyY2UgZnJvbSBB cHBsaWNhdGlvbiBqYXZheC53cy5ycy5jb3JlLkFwcGxpY2F0aW9uDQoyMDE0LTA0LTMwIDA0OjQ3 OjE2LDc5MCBJTkZPICBbb3JnLmpib3NzLnJlc3RlYXN5LnNwaS5SZXN0ZWFzeURlcGxveW1lbnRd IChodHRwLS0wLjAuMC4wLTgwODAtMSkgQWRkaW5nIHNpbmdsZXRvbiByZXNvdXJjZSBvcmcub3Zp cnQuZW5naW5lLmFwaS5yZXN0YXBpLnJlc291cmNlLkJhY2tlbmRWbXNSZXNvdXJjZSBmcm9tIEFw cGxpY2F0aW9uIGphdmF4LndzLnJzLmNvcmUuQXBwbGljYXRpb24NCjIwMTQtMDQtMzAgMDQ6NDc6 MTYsNzkxIElORk8gIFtvcmcuamJvc3MucmVzdGVhc3kuc3BpLlJlc3RlYXN5RGVwbG95bWVudF0g KGh0dHAtLTAuMC4wLjAtODA4MC0xKSBBZGRpbmcgc2luZ2xldG9uIHJlc291cmNlIG9yZy5vdmly dC5lbmdpbmUuYXBpLnJlc3RhcGkucmVzb3VyY2UuQmFja2VuZFRhZ3NSZXNvdXJjZSBmcm9tIEFw cGxpY2F0aW9uIGphdmF4LndzLnJzLmNvcmUuQXBwbGljYXRpb24NCjIwMTQtMDQtMzAgMDQ6NDc6 MTYsNzkxIElORk8gIFtvcmcuamJvc3MucmVzdGVhc3kuc3BpLlJlc3RlYXN5RGVwbG95bWVudF0g KGh0dHAtLTAuMC4wLjAtODA4MC0xKSBBZGRpbmcgc2luZ2xldG9uIHJlc291cmNlIG9yZy5vdmly dC5lbmdpbmUuYXBpLnJlc3RhcGkucmVzb3VyY2UuQmFja2VuZERpc2tzUmVzb3VyY2UgZnJvbSBB cHBsaWNhdGlvbiBqYXZheC53cy5ycy5jb3JlLkFwcGxpY2F0aW9uDQoyMDE0LTA0LTMwIDA0OjQ3 OjE2LDc5MiBJTkZPICBbb3JnLmpib3NzLnJlc3RlYXN5LnNwaS5SZXN0ZWFzeURlcGxveW1lbnRd IChodHRwLS0wLjAuMC4wLTgwODAtMSkgQWRkaW5nIHNpbmdsZXRvbiByZXNvdXJjZSBvcmcub3Zp cnQuZW5naW5lLmFwaS5yZXN0YXBpLnJlc291cmNlLkJhY2tlbmRDbHVzdGVyc1Jlc291cmNlIGZy b20gQXBwbGljYXRpb24gamF2YXgud3MucnMuY29yZS5BcHBsaWNhdGlvbg0KMjAxNC0wNC0zMCAw NDo0NzoxNiw3OTMgSU5GTyAgW29yZy5qYm9zcy5yZXN0ZWFzeS5zcGkuUmVzdGVhc3lEZXBsb3lt ZW50XSAoaHR0cC0tMC4wLjAuMC04MDgwLTEpIEFkZGluZyBzaW5nbGV0b24gcmVzb3VyY2Ugb3Jn Lm92aXJ0LmVuZ2luZS5hcGkucmVzdGFwaS5yZXNvdXJjZS5CYWNrZW5kVGVtcGxhdGVzUmVzb3Vy Y2UgZnJvbSBBcHBsaWNhdGlvbiBqYXZheC53cy5ycy5jb3JlLkFwcGxpY2F0aW9uDQoyMDE0LTA0 LTMwIDA0OjQ3OjE2LDc5NCBJTkZPICBbb3JnLmpib3NzLnJlc3RlYXN5LnNwaS5SZXN0ZWFzeURl cGxveW1lbnRdIChodHRwLS0wLjAuMC4wLTgwODAtMSkgQWRkaW5nIHNpbmdsZXRvbiByZXNvdXJj ZSBvcmcub3ZpcnQuZW5naW5lLmFwaS5yZXN0YXBpLnJlc291cmNlLkJhY2tlbmRTdG9yYWdlU2Vy dmVyQ29ubmVjdGlvbnNSZXNvdXJjZSBmcm9tIEFwcGxpY2F0aW9uIGphdmF4LndzLnJzLmNvcmUu QXBwbGljYXRpb24NCjIwMTQtMDQtMzAgMDQ6NDc6MTYsNzk0IElORk8gIFtvcmcuamJvc3MucmVz dGVhc3kuc3BpLlJlc3RlYXN5RGVwbG95bWVudF0gKGh0dHAtLTAuMC4wLjAtODA4MC0xKSBBZGRp bmcgc2luZ2xldG9uIHJlc291cmNlIG9yZy5vdmlydC5lbmdpbmUuYXBpLnJlc3RhcGkucmVzb3Vy Y2UuQmFja2VuZE5ldHdvcmtzUmVzb3VyY2UgZnJvbSBBcHBsaWNhdGlvbiBqYXZheC53cy5ycy5j b3JlLkFwcGxpY2F0aW9uDQoyMDE0LTA0LTMwIDA0OjQ3OjE3LDAwMyBJTkZPICBbb3JnLmluZmlu aXNwYW4uZmFjdG9yaWVzLkdsb2JhbENvbXBvbmVudFJlZ2lzdHJ5XSAoaHR0cC0tMC4wLjAuMC04 MDgwLTEpIElTUE4wMDAxMjg6IEluZmluaXNwYW4gdmVyc2lvbjogSW5maW5pc3BhbiAnQnJhaG1h JyA1LjEuMi5GSU5BTA0KMjAxNC0wNC0zMCAwNDo0NzoxNywxNjcgSU5GTyAgW29yZy5pbmZpbmlz cGFuLmpteC5DYWNoZUpteFJlZ2lzdHJhdGlvbl0gKGh0dHAtLTAuMC4wLjAtODA4MC0xKSBJU1BO MDAwMDMxOiBNQmVhbnMgd2VyZSBzdWNjZXNzZnVsbHkgcmVnaXN0ZXJlZCB0byB0aGUgcGxhdGZv cm0gbWJlYW4gc2VydmVyLg0KMjAxNC0wNC0zMCAwNDo0NzoxNywxNzEgSU5GTyAgW29yZy5qYm9z cy5hcy5jbHVzdGVyaW5nLmluZmluaXNwYW5dIChodHRwLS0wLjAuMC4wLTgwODAtMSkgSkJBUzAx MDI4MTogU3RhcnRlZCB0aW1lb3V0LWJhc2UgY2FjaGUgZnJvbSBvdmlydC1lbmdpbmUgY29udGFp bmVyDQoyMDE0LTA0LTMwIDA0OjQ3OjE4LDM3NSBFUlJPUiBbb3JnLmFwYWNoZS5jYXRhbGluYS5j b3JlLkNvbnRhaW5lckJhc2UuW2pib3NzLndlYl0uW2RlZmF1bHQtaG9zdF0uWy9hcGldLltvcmcu b3ZpcnQuZW5naW5lLmFwaS5yZXN0YXBpLkJhY2tlbmRBcHBsaWNhdGlvbl1dIChodHRwLS0wLjAu MC4wLTgwODAtMSkgU2VydmxldC5zZXJ2aWNlKCkgZm9yIHNlcnZsZXQgb3JnLm92aXJ0LmVuZ2lu ZS5hcGkucmVzdGFwaS5CYWNrZW5kQXBwbGljYXRpb24gdGhyZXcgZXhjZXB0aW9uOiBvcmcuamJv c3MucmVzdGVhc3kuc3BpLlVuaGFuZGxlZEV4Y2VwdGlvbjogb3JnLmpib3NzLnJlc3RlYXN5LnBs dWdpbnMucHJvdmlkZXJzLmpheGIuSkFYQk1hcnNoYWxFeGNlcHRpb246IENvdWxkIG5vdCBmaW5k IEpBWEJDb250ZXh0RmluZGVyIGZvciBtZWRpYSB0eXBlOiB0ZXh0L2h0bWwNCglhdCBvcmcuamJv c3MucmVzdGVhc3kuY29yZS5TeW5jaHJvbm91c0Rpc3BhdGNoZXIud3JpdGVGYWlsdXJlKFN5bmNo cm9ub3VzRGlzcGF0Y2hlci5qYXZhOjQzNSkgW3Jlc3RlYXN5LWpheHJzLTIuMy4yLkZpbmFsLmph cjpdDQoJYXQgb3JnLmpib3NzLnJlc3RlYXN5LmNvcmUuU3luY2hyb25vdXNEaXNwYXRjaGVyLmV4 ZWN1dGVFeGFjdEV4Y2VwdGlvbk1hcHBlcihTeW5jaHJvbm91c0Rpc3BhdGNoZXIuamF2YToyOTIp IFtyZXN0ZWFzeS1qYXhycy0yLjMuMi5GaW5hbC5qYXI6XQ0KCWF0IG9yZy5qYm9zcy5yZXN0ZWFz eS5jb3JlLlN5bmNocm9ub3VzRGlzcGF0Y2hlci5oYW5kbGVFeGNlcHRpb24oU3luY2hyb25vdXNE aXNwYXRjaGVyLmphdmE6MjA5KSBbcmVzdGVhc3ktamF4cnMtMi4zLjIuRmluYWwuamFyOl0NCglh dCBvcmcuamJvc3MucmVzdGVhc3kuY29yZS5TeW5jaHJvbm91c0Rpc3BhdGNoZXIuaGFuZGxlV3Jp dGVSZXNwb25zZUV4Y2VwdGlvbihTeW5jaHJvbm91c0Rpc3BhdGNoZXIuamF2YToyMDMpIFtyZXN0 ZWFzeS1qYXhycy0yLjMuMi5GaW5hbC5qYXI6XQ0KCWF0IG9yZy5qYm9zcy5yZXN0ZWFzeS5jb3Jl LlN5bmNocm9ub3VzRGlzcGF0Y2hlci5pbnZva2UoU3luY2hyb25vdXNEaXNwYXRjaGVyLmphdmE6 NTEwKSBbcmVzdGVhc3ktamF4cnMtMi4zLjIuRmluYWwuamFyOl0NCglhdCBvcmcuamJvc3MucmVz dGVhc3kuY29yZS5TeW5jaHJvbm91c0Rpc3BhdGNoZXIuaW52b2tlKFN5bmNocm9ub3VzRGlzcGF0 Y2hlci5qYXZhOjExOSkgW3Jlc3RlYXN5LWpheHJzLTIuMy4yLkZpbmFsLmphcjpdDQoJYXQgb3Jn Lmpib3NzLnJlc3RlYXN5LnBsdWdpbnMuc2VydmVyLnNlcnZsZXQuU2VydmxldENvbnRhaW5lckRp c3BhdGNoZXIuc2VydmljZShTZXJ2bGV0Q29udGFpbmVyRGlzcGF0Y2hlci5qYXZhOjIwOCkgW3Jl c3RlYXN5LWpheHJzLTIuMy4yLkZpbmFsLmphcjpdDQoJYXQgb3JnLmpib3NzLnJlc3RlYXN5LnBs dWdpbnMuc2VydmVyLnNlcnZsZXQuSHR0cFNlcnZsZXREaXNwYXRjaGVyLnNlcnZpY2UoSHR0cFNl cnZsZXREaXNwYXRjaGVyLmphdmE6NTUpIFtyZXN0ZWFzeS1qYXhycy0yLjMuMi5GaW5hbC5qYXI6 XQ0KCWF0IG9yZy5qYm9zcy5yZXN0ZWFzeS5wbHVnaW5zLnNlcnZlci5zZXJ2bGV0Lkh0dHBTZXJ2 bGV0RGlzcGF0Y2hlci5zZXJ2aWNlKEh0dHBTZXJ2bGV0RGlzcGF0Y2hlci5qYXZhOjUwKSBbcmVz dGVhc3ktamF4cnMtMi4zLjIuRmluYWwuamFyOl0NCglhdCBqYXZheC5zZXJ2bGV0Lmh0dHAuSHR0 cFNlcnZsZXQuc2VydmljZShIdHRwU2VydmxldC5qYXZhOjg0NykgW2pib3NzLXNlcnZsZXQtYXBp XzMuMF9zcGVjLTEuMC4wLkZpbmFsLmphcjoxLjAuMC5GaW5hbF0NCglhdCBvcmcuYXBhY2hlLmNh dGFsaW5hLmNvcmUuQXBwbGljYXRpb25GaWx0ZXJDaGFpbi5pbnRlcm5hbERvRmlsdGVyKEFwcGxp Y2F0aW9uRmlsdGVyQ2hhaW4uamF2YTozMjkpIFtqYm9zc3dlYi03LjAuMTMuRmluYWwuamFyOl0N CglhdCBvcmcuYXBhY2hlLmNhdGFsaW5hLmNvcmUuQXBwbGljYXRpb25GaWx0ZXJDaGFpbi5kb0Zp bHRlcihBcHBsaWNhdGlvbkZpbHRlckNoYWluLmphdmE6MjQ4KSBbamJvc3N3ZWItNy4wLjEzLkZp bmFsLmphcjpdDQoJYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmFhYS5BdXRoZW50aWNhdGlvbkZp bHRlci5kb0ZpbHRlcihBdXRoZW50aWNhdGlvbkZpbHRlci5qYXZhOjg0KSBbYWFhLmphcjpdDQoJ YXQgb3JnLmFwYWNoZS5jYXRhbGluYS5jb3JlLkFwcGxpY2F0aW9uRmlsdGVyQ2hhaW4uaW50ZXJu YWxEb0ZpbHRlcihBcHBsaWNhdGlvbkZpbHRlckNoYWluLmphdmE6MjgwKSBbamJvc3N3ZWItNy4w LjEzLkZpbmFsLmphcjpdDQoJYXQgb3JnLmFwYWNoZS5jYXRhbGluYS5jb3JlLkFwcGxpY2F0aW9u RmlsdGVyQ2hhaW4uZG9GaWx0ZXIoQXBwbGljYXRpb25GaWx0ZXJDaGFpbi5qYXZhOjI0OCkgW2pi b3Nzd2ViLTcuMC4xMy5GaW5hbC5qYXI6XQ0KCWF0IG9yZy5hcGFjaGUuY2F0YWxpbmEuY29yZS5T dGFuZGFyZFdyYXBwZXJWYWx2ZS5pbnZva2UoU3RhbmRhcmRXcmFwcGVyVmFsdmUuamF2YToyNzUp IFtqYm9zc3dlYi03LjAuMTMuRmluYWwuamFyOl0NCglhdCBvcmcuYXBhY2hlLmNhdGFsaW5hLmNv cmUuU3RhbmRhcmRDb250ZXh0VmFsdmUuaW52b2tlKFN0YW5kYXJkQ29udGV4dFZhbHZlLmphdmE6 MTYxKSBbamJvc3N3ZWItNy4wLjEzLkZpbmFsLmphcjpdDQoJYXQgb3JnLmFwYWNoZS5jYXRhbGlu YS5hdXRoZW50aWNhdG9yLkF1dGhlbnRpY2F0b3JCYXNlLmludm9rZShBdXRoZW50aWNhdG9yQmFz ZS5qYXZhOjQ4OSkgW2pib3Nzd2ViLTcuMC4xMy5GaW5hbC5qYXI6XQ0KCWF0IG9yZy5qYm9zcy5h cy53ZWIuc2VjdXJpdHkuU2VjdXJpdHlDb250ZXh0QXNzb2NpYXRpb25WYWx2ZS5pbnZva2UoU2Vj dXJpdHlDb250ZXh0QXNzb2NpYXRpb25WYWx2ZS5qYXZhOjE1MykgW2pib3NzLWFzLXdlYi03LjEu MS5GaW5hbC5qYXI6Ny4xLjEuRmluYWxdDQoJYXQgb3JnLmFwYWNoZS5jYXRhbGluYS5jb3JlLlN0 YW5kYXJkSG9zdFZhbHZlLmludm9rZShTdGFuZGFyZEhvc3RWYWx2ZS5qYXZhOjE1NSkgW2pib3Nz d2ViLTcuMC4xMy5GaW5hbC5qYXI6XQ0KCWF0IG9yZy5hcGFjaGUuY2F0YWxpbmEudmFsdmVzLkVy cm9yUmVwb3J0VmFsdmUuaW52b2tlKEVycm9yUmVwb3J0VmFsdmUuamF2YToxMDIpIFtqYm9zc3dl Yi03LjAuMTMuRmluYWwuamFyOl0NCglhdCBvcmcuamJvc3Mud2ViLnJld3JpdGUuUmV3cml0ZVZh bHZlLmludm9rZShSZXdyaXRlVmFsdmUuamF2YTo0NjYpIFtqYm9zc3dlYi03LjAuMTMuRmluYWwu amFyOl0NCglhdCBvcmcuYXBhY2hlLmNhdGFsaW5hLmNvcmUuU3RhbmRhcmRFbmdpbmVWYWx2ZS5p bnZva2UoU3RhbmRhcmRFbmdpbmVWYWx2ZS5qYXZhOjEwOSkgW2pib3Nzd2ViLTcuMC4xMy5GaW5h bC5qYXI6XQ0KCWF0IG9yZy5hcGFjaGUuY2F0YWxpbmEuY29ubmVjdG9yLkNveW90ZUFkYXB0ZXIu c2VydmljZShDb3lvdGVBZGFwdGVyLmphdmE6MzY4KSBbamJvc3N3ZWItNy4wLjEzLkZpbmFsLmph cjpdDQoJYXQgb3JnLmFwYWNoZS5jb3lvdGUuaHR0cDExLkh0dHAxMVByb2Nlc3Nvci5wcm9jZXNz KEh0dHAxMVByb2Nlc3Nvci5qYXZhOjg3NykgW2pib3Nzd2ViLTcuMC4xMy5GaW5hbC5qYXI6XQ0K CWF0IG9yZy5hcGFjaGUuY295b3RlLmh0dHAxMS5IdHRwMTFQcm90b2NvbCRIdHRwMTFDb25uZWN0 aW9uSGFuZGxlci5wcm9jZXNzKEh0dHAxMVByb3RvY29sLmphdmE6NjcxKSBbamJvc3N3ZWItNy4w LjEzLkZpbmFsLmphcjpdDQoJYXQgb3JnLmFwYWNoZS50b21jYXQudXRpbC5uZXQuSklvRW5kcG9p bnQkV29ya2VyLnJ1bihKSW9FbmRwb2ludC5qYXZhOjkzMCkgW2pib3Nzd2ViLTcuMC4xMy5GaW5h bC5qYXI6XQ0KCWF0IGphdmEubGFuZy5UaHJlYWQucnVuKFRocmVhZC5qYXZhOjc0NCkgW3J0Lmph cjoxLjcuMF81NV0NCkNhdXNlZCBieTogb3JnLmpib3NzLnJlc3RlYXN5LnBsdWdpbnMucHJvdmlk ZXJzLmpheGIuSkFYQk1hcnNoYWxFeGNlcHRpb246IENvdWxkIG5vdCBmaW5kIEpBWEJDb250ZXh0 RmluZGVyIGZvciBtZWRpYSB0eXBlOiB0ZXh0L2h0bWwNCglhdCBvcmcuamJvc3MucmVzdGVhc3ku cGx1Z2lucy5wcm92aWRlcnMuamF4Yi5BYnN0cmFjdEpBWEJQcm92aWRlci5maW5kSkFYQkNvbnRl eHQoQWJzdHJhY3RKQVhCUHJvdmlkZXIuamF2YTo2NykgW3Jlc3RlYXN5LWpheGItcHJvdmlkZXIt Mi4zLjIuRmluYWwuamFyOl0NCglhdCBvcmcuamJvc3MucmVzdGVhc3kucGx1Z2lucy5wcm92aWRl cnMuamF4Yi5BYnN0cmFjdEpBWEJQcm92aWRlci5nZXRNYXJzaGFsbGVyKEFic3RyYWN0SkFYQlBy b3ZpZGVyLmphdmE6MTY2KSBbcmVzdGVhc3ktamF4Yi1wcm92aWRlci0yLjMuMi5GaW5hbC5qYXI6 XQ0KCWF0IG9yZy5qYm9zcy5yZXN0ZWFzeS5wbHVnaW5zLnByb3ZpZGVycy5qYXhiLkFic3RyYWN0 SkFYQlByb3ZpZGVyLndyaXRlVG8oQWJzdHJhY3RKQVhCUHJvdmlkZXIuamF2YToxNDIpIFtyZXN0 ZWFzeS1qYXhiLXByb3ZpZGVyLTIuMy4yLkZpbmFsLmphcjpdDQoJYXQgb3JnLmpib3NzLnJlc3Rl YXN5LmNvcmUuU2VydmVyUmVzcG9uc2Uud3JpdGVUbyhTZXJ2ZXJSZXNwb25zZS5qYXZhOjI0Mykg W3Jlc3RlYXN5LWpheHJzLTIuMy4yLkZpbmFsLmphcjpdDQoJYXQgb3JnLmpib3NzLnJlc3RlYXN5 LmNvcmUuU3luY2hyb25vdXNEaXNwYXRjaGVyLndyaXRlSmF4cnNSZXNwb25zZShTeW5jaHJvbm91 c0Rpc3BhdGNoZXIuamF2YTo1ODUpIFtyZXN0ZWFzeS1qYXhycy0yLjMuMi5GaW5hbC5qYXI6XQ0K CWF0IG9yZy5qYm9zcy5yZXN0ZWFzeS5jb3JlLlN5bmNocm9ub3VzRGlzcGF0Y2hlci53cml0ZUZh aWx1cmUoU3luY2hyb25vdXNEaXNwYXRjaGVyLmphdmE6NDIyKSBbcmVzdGVhc3ktamF4cnMtMi4z LjIuRmluYWwuamFyOl0NCgkuLi4gMjcgbW9yZQ0KDQoyMDE0LTA0LTMwIDA0OjQ3OjM0LDYwOCBJ TkZPICBbb3JnLmFwYWNoZS5jb3lvdGUuaHR0cDExLkh0dHAxMVByb3RvY29sXSAoTVNDIHNlcnZp Y2UgdGhyZWFkIDEtOCkgUGF1c2luZyBDb3lvdGUgSFRUUC8xLjEgb24gaHR0cC0tMC4wLjAuMC04 MDgwDQoyMDE0LTA0LTMwIDA0OjQ3OjM0LDYwOSBJTkZPICBbb3JnLmFwYWNoZS5jb3lvdGUuaHR0 cDExLkh0dHAxMVByb3RvY29sXSAoTVNDIHNlcnZpY2UgdGhyZWFkIDEtOCkgU3RvcHBpbmcgQ295 b3RlIEhUVFAvMS4xIG9uIGh0dHAtLTAuMC4wLjAtODA4MA0KMjAxNC0wNC0zMCAwNDo0NzozNCw2 MTMgSU5GTyAgW29yZy5hcGFjaGUuY295b3RlLmh0dHAxMS5IdHRwMTFQcm90b2NvbF0gKE1TQyBz ZXJ2aWNlIHRocmVhZCAxLTMpIFBhdXNpbmcgQ295b3RlIEhUVFAvMS4xIG9uIGh0dHAtLTAuMC4w LjAtODQ0Mw0KMjAxNC0wNC0zMCAwNDo0NzozNCw2MTQgSU5GTyAgW29yZy5hcGFjaGUuY295b3Rl Lmh0dHAxMS5IdHRwMTFQcm90b2NvbF0gKE1TQyBzZXJ2aWNlIHRocmVhZCAxLTMpIFN0b3BwaW5n IENveW90ZSBIVFRQLzEuMSBvbiBodHRwLS0wLjAuMC4wLTg0NDM= --_002_B63C858E777679458338A30A991BB52401624855G1W3780americas_--

3 5

short recap of last vdsm call (15.4.2014)
by ybronhei 05 May '14

05 May '14

hey, somehow we missed the summary of this call, and few "big" issues were raised there. so i would like to share it with all and hear more comments - task id in http header - allows engine to initiate calls with id instead of following vdsm response - federico already started this work, and this is mandatory for live merge feature afaiu. - fromani: Suggested thread pool for libvirt-related operations. if this can be elaborated more, please do. i don't recall the details or other alternatives. - danken: we should press on with the patches that keep VMs in Down state: removing them on vdsm restart keeps lvs in activated state which may spell trouble - splitting vdsm infra\generic code to sub-vdsm-module instead of creating separate packages. This can be done by splitting the git repository to allow "easy" maintenance of the code (from infra prospective) which includes also C parts and generic tools that can be used in other projects as well. if i missed anything, please add thanks, -- Yaniv Bronhaim.

4 10

RHEVM 3.2 ReST API VM memory used statistic
by Vikas Kokare 05 May '14

05 May '14

The "memory.used" statistic on a virtual machine is returning a negative value , ie. <statistic href="/api/vms/260f8508-2bea-4202-9b93-f8f0dcddc334/statistics/b7499508-c1c3-32f0-8174-c1783e57bb08" id="b7499508-c1c3-32f0-8174-c1783e57bb08"><name>memory.used</name><description>Memory used (agent)</description><values type="INTEGER"><value><datum>*-2061584303*</datum></value></values><type>GAUGE</type><unit>BYTES</unit><vm href="/api/vms/260f8508-2bea-4202-9b93-f8f0dcddc334" id="260f8508-2bea-4202-9b93-f8f0dcddc334"/></statistic> by the RHEVM 3.2 ReST API. while, in the Web Administration Console, memory consumption for the same VM, shows a positive percentage value. Is this an issue with the ReST API?

2 5

[QE] oVirt 3.4.1 RC status
by Sandro Bonazzola 05 May '14

05 May '14

Hi, We're going to tart composing oVirt 3.4.1 RC on 2014-04-23 09:00 UTC from 3.4 branches. The bug tracker [1] shows no blocking bugs for the release There are still 302 bugs [2] targeted to 3.4.1. Excluding node and documentation bugs we still have 184 bugs [3] targeted to 3.4.1. Please review them as soon as possible and retarget them to a future release. Maintainers / Assignee: - Please remember to rebuild your packages before 2014-04-23 09:00 UTC if you don't want to use ovirt-3.4-snapshot packages - Please add the bugs to the tracker if you think that 3.4.1 should not be released without them fixed. - Please update the target to any next release for bugs that won't be in 3.4.1: it will ease gathering the blocking bugs for next releases. - Please fill release notes, the page has been created here [4] - If you're going to test this release, please add yourself to the test page [5] [1] https://bugzilla.redhat.com/1080483 [2] http://red.ht/1gCFOtH [3] http://red.ht/1laBSUj [4] http://www.ovirt.org/OVirt_3.4.1_release_notes [5] http://www.ovirt.org/Testing/oVirt_3.4.1_testing -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

3 7

Re: [ovirt-devel] Fwd: rpm deps
by Dan Kenigsberg 05 May '14

05 May '14

On Wed, Apr 30, 2014 at 09:41:40AM -0400, Piotr Kliczewski wrote: > Adding to the discussion. Your CC line was too huge. devel(a)ovirt.org should be used to such discussions. > > Currently vdsm-xmlrpc rpm is required by vdsm and vdsm-cli rpms. Initially I suggested to have vdsm-jsonrpc required by vdsm-api but it do not seems to be good idea. > I think that we need to add that dept to vdsm rpm in the same way as it is for vdsm-xmlrpc. > > I do not understand why we have decided to split jsonrpc code between two rpms: > > vdms-api: > - vdsmapi-schema.json > > vdsm-jsonrpc: > - BindingJsonRpc > - Bridge > > vdsm-yajsonrpc: > - __init__ > - betterAsyncore > - stomp > - stompReactor > > I understand that we may have schema in api package but do we really need two packages for jsonrpc? > Currently we need a package for stomp reactor so I suggest for now to have one json(stomp) rpm and > create second for amqp when there will be need for it. I believe that the motivation for the current packaging was that - yajsonrpc is not strictly vdsm-related. It is a candidate for a spin-off - jsonrpc is sever-side only - api might be needed by clients, too. But I hope we'd have reasonable inspection to avoid this need. As long as vdsm can work without jsonrpc, I'd rather that it does not require the package. When we move away of xmlrpc, we could drop the xmlrpc requirement, too. Dan.

3 2

Re: [ovirt-devel] Sanlock fencing reservations
by Dan Kenigsberg 04 May '14

04 May '14

On Wed, Feb 26, 2014 at 11:14:33AM -0500, Saggi Mizrahi wrote: > I've recently been introduced to the this feature and I was wondering is this really > the correct way to go for solving this particular problem. > > My main issue is with making two unrelated flow dependent. > By pushing this into the existing sanlock data structures you limit yourself > in the future from changing either to optimize or even solve problems for a > single use case. > > Having an independent daemon to perform this task will give more room as to > how to implement the feature. Saggi, are you thinking about something similar to fence_sanlockd http://linux.die.net/man/8/fence_sanlockd and its client fence_sanlock? Using them, instead of reimplementing parts of them within Vdsm, seem reasonable in first glance. However http://www.ovirt.org/Features/Sanlock_Fencing#Why_not_use_fence_sanlockd.3F claim that it wastes 2G of storage and requires explicit master domain upgrade. Nir, could you explain why so much space is required by sanlockd? Can it be configured to use smaller area? > > I don't want to reach a situation where we need to change a sanlock struct > and not be able to do it as it makes problems with fencing flows. > > I believe in the mantra that things should do one thing and do it well. > This feels like an ad-hoc solution to a very niche problem. > > > Further more, it kind of seems like a mailbox issue. > Leaving a fencing request is just a message. In the > future I can see it just being a suspend-to-disk request > so that you don't even have to fence the host in such cases. > > The only reason I see people putting it to sanlock is > that it's a daemon that reads from disk and has does fencing. > > I agree that in VDSMs current state putting this in the mailbox > is unreliable to say the least but it doesn't mean that we can't > have a small independent daemon to do the task until we get > messaging in VDSM to a stable state. > > IMHO it's better than having it as and ad-hoc feature to sanlock. > A feature which we can't remove later as someone might depend on it. > A feature that might limit us or that we might even abandon once we > have more reliable disk based messaging in VDSM.

4 3

[Features] Special Request for Feature Page Cleanup Projecy
by Brian Proffitt 01 May '14

01 May '14

All: It has been requested that we add date/timestamps to the Features pages in order to highlight the age of each page and assist users in determining how fresh information is. After investigating various options to do this within the database or using automated code, it seems that the old-fashioned manual way is still the best option. This is because an automated solution would only insert the needed strings, but not the actual data that pertains to that feature. To divide this work among the community, I have made an inventory of all of the features pages in the oVirt.org site as of 3/30/14, located at http://bit.ly/1iA1HQ3. If everyone can take a look at this sheet (check the tabs on the bottom, too) and find the pages they created or for which they are responsible, the following steps should be taken for pages that are marked "Yes" in "Needs Datestamp": 1. Add the following line to the top of each page, under the first heading: {{Feature|name=[Name of Feature]}|modules=[Node(s) of feature]|version=[oVirt version number]|status=Released}} 2. On the Feature page spreadsheet on Google Docs, change the "Yes" in "Needs Datestamp" to "No." This new Feature template string will add the time and date information to the page automatically. If, along the way, you find features that have been deprecated, or feature pages that are duplicates, these pages should be cleaned up as well. Ideally, this should not take too much time for each individual, and the effort will be a big step towards documentation consistency on the oVirt site. If you have any questions/concerns, send them my way. Thanks, BKP -- Brian Proffitt oVirt Community Manager Project Atomic Community Lead Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC

2 2

Adjust engine to support arbitrary vlan device name
by Alona Kaplan 01 May '14

01 May '14

Hi all, This refactoring is targeted to 3.5. Please review the feature page and share your thoughts: http://www.ovirt.org/Feature/ArbitraryVlanDeviceName Thanks, Alona

4 5

vdsm installation error on fc20
by Vered Volansky 30 Apr '14

30 Apr '14

Hi, I'm trying to install vdsm on a fedora20 machine with the following error. I've been following http://www.ovirt.org/Download#Fedora_Installation_Instructions . I've also tried "yum clean all" - to no avail. Any idea anybody? Thanks, Vered ====================== ============================================================================================================================================================================================= Package Arch Version Repository Size =================================================================================================================================================================================================================== Installing: vdsm x86_64 4.14.6-0.fc20 ovirt-3.4-stable 752 k Installing for dependencies: vdsm-python x86_64 4.14.6-0.fc20 ovirt-3.4-stable 134 k vdsm-python-zombiereaper noarch 4.14.6-0.fc20 ovirt-3.4-stable 18 k vdsm-xmlrpc noarch 4.14.6-0.fc20 ovirt-3.4-stable 35 k Transaction Summary =================================================================================================================================================================================================================== Install 1 Package (+3 Dependent packages) Total download size: 938 k Installed size: 3.5 M Is this ok [y/d/N]: y Downloading packages: warning: /var/cache/yum/x86_64/20/ovirt-3.4-stable/packages/vdsm-python-4.14.6-0.fc20.x86_64.rpm: Header V4 RSA/SHA1 Signature, key ID fe590cb7: NOKEY ] 117 kB/s | 127 kB 00:00:06 ETA Public key for vdsm-python-4.14.6-0.fc20.x86_64.rpm is not installed (1/4): vdsm-python-4.14.6-0.fc20.x86_64.rpm | 134 kB 00:00:01 (2/4): vdsm-python-zombiereaper-4.14.6-0.fc20.noarch.rpm | 18 kB 00:00:00 (3/4): vdsm-xmlrpc-4.14.6-0.fc20.noarch.rpm | 35 kB 00:00:00 (4/4): vdsm-4.14.6-0.fc20.x86_64.rpm | 752 kB 00:00:03 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Total 236 kB/s | 938 kB 00:00:03 Public key for vdsm-python-zombiereaper-4.14.6-0.fc20.noarch.rpm is not installed

2 1

Re: [ovirt-devel] Sanlock fencing reservations
by Nir Soffer 30 Apr '14

30 Apr '14

----- Original Message ----- > From: "Saggi Mizrahi" <smizrahi(a)redhat.com> > To: "arch" <arch(a)ovirt.org> > Cc: "Nir Soffer" <nsoffer(a)redhat.com>, "David Teigland" <teigland(a)redhat.com> > Sent: Wednesday, February 26, 2014 6:14:33 PM > Subject: Sanlock fencing reservations > > I've recently been introduced to the this feature and I was wondering is this > really > the correct way to go for solving this particular problem. > > My main issue is with making two unrelated flow dependent. Hi Saggi, Sorry for the late response. The flows are related - sanlock already fencing as part of the lease and resources keeping. > By pushing this into the existing sanlock data structures you limit yourself > in the future from changing either to optimize or even solve problems for a > single use case. I agree, we have 196 unused bits in the sanlock lease, which can be used for other needs if we don't used them the new host_message api. We can keep the extra space forever - or use it now. > > Having an independent daemon to perform this task will give more room as to > how to implement the feature. I agree, but we are not designing this system from scratch, and adding this feature to the existing daemon is easy and makes sense. I thinks this is a good trade-off. > > I don't want to reach a situation where we need to change a sanlock struct > and not be able to do it as it makes problems with fencing flows. This is the price for choosing this way. > > I believe in the mantra that things should do one thing and do it well. > This feels like an ad-hoc solution to a very niche problem. > > > Further more, it kind of seems like a mailbox issue. > Leaving a fencing request is just a message. In the > future I can see it just being a suspend-to-disk request > so that you don't even have to fence the host in such cases. > > The only reason I see people putting it to sanlock is > that it's a daemon that reads from disk and has does fencing. > > I agree that in VDSMs current state putting this in the mailbox > is unreliable to say the least but it doesn't mean that we can't > have a small independent daemon to do the task until we get > messaging in VDSM to a stable state. > > IMHO it's better than having it as and ad-hoc feature to sanlock. > A feature which we can't remove later as someone might depend on it. > A feature that might limit us or that we might even abandon once we > have more reliable disk based messaging in VDSM. > I don't think we need another daemon that duplicate most of what sanlock is doing now, and I would not mix critical messages (fencing) with everyday messages in such new messaging solution. Regards, Nir

1 0

oVirt sources tagging
by Sandro Bonazzola 30 Apr '14

30 Apr '14

Hi, today I've seen that ovirt-hosted-engine-ha was missing proper tagging of version released. I've not checked all projects so this is just a reminder. Maintainers, please ensure that all previous releases are properly tagged (at least GA ones, but RC and beta are recommended too) and please remember to tag each time you release a new tarball. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

UI plugins using REST API
by Vojtech Szocs 30 Apr '14

30 Apr '14

Hi guys, just a quick note on UI plugin vs. REST API integration, there are currently two ways to work with REST API: * (standard) /ovirt-engine/api * (legacy) /api Please don't use the legacy URL, since "sessionId" that is acquired via RestApiSessionAcquired event handler [1] works only for the standard URL. (Also, don't forget to include "Prefer:persistent-auth" header when making calls that shouldn't close the session.) [1] http://www.ovirt.org/Features/UIPlugins#REST_API_integration Regards, Vojtech

4 7

oVirt 3.4.1 branching
by Sandro Bonazzola 30 Apr '14

30 Apr '14

Hi, we're going to create ovirt-engine-3.4.1 branch tomorrow morning 08:00 UTC in order to allow 3.4.2 development starting on 3.4 branch while we prepare for 3.4.1 GA release. So starting tomorrow morning, if you have patches targeted to 3.4.1 you'll need to push them on 3.4.1 branch too. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 1

short recap of today's vdsm call (29.4.2014)
by Dan Kenigsberg 29 Apr '14

29 Apr '14

Few things mentioned on today's call: - ovirt-3.3 is no longer supported: only security patches need to be merged there. - fenceSpmStorage turned into noop - intenetionally - infra code is expected to move around to its own subdir, as warned 2 weeks ago. - with pthreading used, any os.fork() causes a nasty warning Bug 1084500 - threading._after_fork spews "cannot notify on un-acquired lock" when os.fork is called from a thread - a huge json-rpc by Piotr needs to be broken to manageable pieces and reviewed. - Adam to create json-to-yaml schema conversion script (as a backward task) - sanlock fencing - Saggi's worries are to be addressed on the mailing list thread.

1 0

Re: [ovirt-devel] [vdsm] Missing numactl
by Vinzenz Feenstra 29 Apr '14

29 Apr '14

Seems pretty much like it On 04/28/2014 12:30 PM, Piotr Kliczewski wrote: > Hello, > > I pulled the latest changes from master to test my code and during > getCaps I got: > > Thread-14::ERROR::2014-04-28 > 12:11:44,394::__init__::484::jsonrpc.JsonRpcServer::(_serveRequest) > [Errno 2] No such file or directory > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line > 480, in _serveRequest > res = method(**params) > File "/usr/share/vdsm/Bridge.py", line 211, in _dynamicMethod > result = fn(*methodArgs) > File "/usr/share/vdsm/API.py", line 1184, in getCapabilities > c = caps.get() > File "/usr/share/vdsm/caps.py", line 459, in get > caps['numaNodeDistance'] = _getNumaNodeDistance() > File "/usr/lib64/python2.7/site-packages/vdsm/utils.py", line 1003, > in __call__ > value = self.func(*args) > File "/usr/share/vdsm/caps.py", line 209, in _getNumaNodeDistance > retcode, out, err = utils.execCmd(['numactl', '--hardware']) > File "/usr/lib64/python2.7/site-packages/vdsm/utils.py", line 732, in execCmd > deathSignal=deathSignal, childUmask=childUmask) > File "/usr/lib64/python2.7/site-packages/cpopen/__init__.py", line > 50, in __init__ > stderr=PIPE) > File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__ > errread, errwrite) > File "/usr/lib64/python2.7/site-packages/cpopen/__init__.py", line > 80, in _execute_child_v275 > self._childUmask) > OSError: [Errno 2] No such file or directory > > When I installed numactl rpm getCaps work again. > > Do we need to add this dependency to spec file? > > Thanks, > Piotr > _______________________________________________ > vdsm-devel mailing list > vdsm-devel(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel -- Regards, Vinzenz Feenstra | Senior Software Engineer RedHat Engineering Virtualization R & D Phone: +420 532 294 625 IRC: vfeenstr or evilissimo Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1

[Devel] QoS Aggregate
by Gilad Chaplik 29 Apr '14

29 Apr '14

Hi list, While oVirt is rapidly continues to grow and gather features, it’s important to wrap already existing features with new ones, for better UX reasons. In oVirt 3.5, there are going to be 2 new QoS objects, CPU limits and blkio limits, added to the existing one network QoS (since 3.3). You are more than welcome to review my proposal to aggregate all features under the same umbrella: http://www.ovirt.org/Features/aggregate_QoS Thanks, Gilad.

2 4

Cooking with Python?
by Nir Soffer 29 Apr '14

29 Apr '14

You may like this free (as beer) online version: http://chimera.labs.oreilly.com/books/1230000000393 Nir

1 0

Fwd: [vdsm] Missing numactl
by Piotr Kliczewski 28 Apr '14

28 Apr '14

Hello, I pulled the latest changes from master to test my code and during getCaps I got: Thread-14::ERROR::2014-04-28 12:11:44,394::__init__::484::jsonrpc.JsonRpcServer::(_serveRequest) [Errno 2] No such file or directory Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 480, in _serveRequest res = method(**params) File "/usr/share/vdsm/Bridge.py", line 211, in _dynamicMethod result = fn(*methodArgs) File "/usr/share/vdsm/API.py", line 1184, in getCapabilities c = caps.get() File "/usr/share/vdsm/caps.py", line 459, in get caps['numaNodeDistance'] = _getNumaNodeDistance() File "/usr/lib64/python2.7/site-packages/vdsm/utils.py", line 1003, in __call__ value = self.func(*args) File "/usr/share/vdsm/caps.py", line 209, in _getNumaNodeDistance retcode, out, err = utils.execCmd(['numactl', '--hardware']) File "/usr/lib64/python2.7/site-packages/vdsm/utils.py", line 732, in execCmd deathSignal=deathSignal, childUmask=childUmask) File "/usr/lib64/python2.7/site-packages/cpopen/__init__.py", line 50, in __init__ stderr=PIPE) File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__ errread, errwrite) File "/usr/lib64/python2.7/site-packages/cpopen/__init__.py", line 80, in _execute_child_v275 self._childUmask) OSError: [Errno 2] No such file or directory When I installed numactl rpm getCaps work again. Do we need to add this dependency to spec file? Thanks, Piotr

1 0