May 2014 - Devel - oVirt List Archives

Call for Papers Deadline in 10 days: PostgresOpen 2014
by Brian Proffitt 20 May '14

20 May '14

Conference: PostgresOpen 2014 Information: PostgresOpen 2014 will be held on September 17 - 19th in Chicago at the Hotel Sax. It will cover topics for PostgreSQL users, developers and contributors, as well as decision and policy makers. Date: Sept 17-19, 2014 Location: Chicago, IL Website: https://postgresopen.org/2014/ Call for Papers Deadline: May 30, 2014 Call for Papers URL: https://postgresopen.org/2014/callforpapers/ -- 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

1 0

Call for Papers Deadline on Sunday: DevOps Enterprise Summit
by Brian Proffitt 20 May '14

20 May '14

Conference: DevOps Enterprise Summit Information: DevOps Enterprise will assemble some of the best practitioners and leaders in the DevOps space, who are transforming how software and services are delivered in large, complex organizations Date: Oct 21-23, 2014 Location: San Francisco Bay Area, CA Website: http://devopsenterprisesummit.com/ Call for Papers Deadline: May 25, 2014 Call for Papers URL: https://docs.google.com/a/proffitt.org/forms/d/13-4lAYwcUmNeIS5tLRK0hshHVh5… -- 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

1 0

Re: [ovirt-devel] latest python-lxml python-ethtool break VDSM on f19
by Douglas Schilling Landgraf 20 May '14

20 May '14

Hi, On 05/19/2014 01:47 PM, Douglas Schilling Landgraf wrote: > On 05/12/2014 03:46 AM, Antoni Segura Puimedon wrote: >> >> >> ----- Original Message ----- >>> From: "Roy Golan" <rgolan(a)redhat.com> >>> To: devel(a)ovirt.org, "Yaniv Bronheim" <ybronhei(a)redhat.com>, >>> "Francesco Romani" <fromani(a)redhat.com> >>> Cc: "Gianluca Cecchi" <gianluca.cecchi(a)gmail.com> >>> Sent: Monday, May 12, 2014 8:13:01 AM >>> Subject: [ovirt-devel] latest python-lxml python-ethtool break VDSM >>> on f19 >>> >>> FYI and please guide Gianluca against what to open a BZ >> >> I don't think python-lxml is related. I think it's only python-ethtool. >>> >>> >>> >>> -------- Original Message -------- >>> Subject: Re: [ovirt-users] getVdsCapabilites unexpected exception >>> [was: Re: >>> AIO 3.4 on fedora 19 initial errors before coming up] >>> Date: Sun, 11 May 2014 23:49:06 +0200 >>> From: Gianluca Cecchi <gianluca.cecchi(a)gmail.com> >>> To: Roy Golan <rgolan(a)redhat.com> >>> CC: users <users(a)ovirt.org> >>> >>> >>> >>> >>> On Sun, May 11, 2014 at 8:41 PM, Gianluca Cecchi < >>> gianluca.cecchi(a)gmail.com >>>> wrote: >>> >>> >>> >>> >>> On Sun, May 11, 2014 at 8:18 PM, Gianluca Cecchi < >>> gianluca.cecchi(a)gmail.com >>>> wrote: >>> >>> >>> >>> On Sun, May 11, 2014 at 4:10 PM, Roy Golan < rgolan(a)redhat.com > wrote: >>> >>> >>> >>> >>> The vm will stay in "Waiting.." as the getVdsCaps is failing and the >>> monitoring of Vms will not take place. >>> need to fix this "Unexpected error" first. is it a matter of ssl enabled >>> configuration for host communication? i.e. can you try vdsClient -s 0 >>> getVdsCaps ? >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >>> >>> >>> I didn't change anything on this server. >>> It is an all-in-one config so both engine and vdsm host are on it. >>> Yesterday and every previous day I was able to start the system and >>> start the >>> VM; I only applied the yum update command yeseterday >>> (with --exclude=sos due to the opened bug) and then I made shutdown >>> of the >>> system. >>> Today after startup I got this problem. >>> >>> [root@tekkaman vdsm]# vdsClient -s 0 getVdsCaps >>> Unexpected exception >>> >>> it seems the error in vdsm.log when I run the command above is of >>> this type: >>> >>> Thread-25::ERROR::2014-05-11 >>> 20:18:02,202::BindingXMLRPC::1086::vds::(wrapper) unexpected error >>> Traceback (most recent call last): >>> File "/usr/share/vdsm/BindingXMLRPC.py", line 1070, in wrapper >>> res = f(*args, **kwargs) >>> File "/usr/share/vdsm/BindingXMLRPC.py", line 393, in getCapabilities >>> ret = api.getCapabilities() >>> File "/usr/share/vdsm/API.py", line 1185, in getCapabilities >>> c = caps.get() >>> File "/usr/share/vdsm/caps.py", line 369, in get >>> caps.update(netinfo.get()) >>> File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 557, >>> in get >>> netAttr.get('qosOutbound')) >>> File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 487, in >>> _getNetInfo >>> ipv4addr, ipv4netmask, ipv6addrs = getIpInfo(iface) >>> File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 317, in >>> getIpInfo >>> ipv6addrs = devInfo.get_ipv6_addresses() >>> SystemError: error return without exception set >>> >>> >>> Based on above errors, I think that for some reason these two python >>> related >>> packages that were updated yesterday are causing some problems with >>> vdsm. >>> Can you confirm that you can run ok the 3.4 vdsm with those? >>> >>> vdsm-4.14.6-0.fc19.x86_64 >>> >>> >>> May 10 21:24:23 Updated: python-ethtool-0.9-2.fc19.x86_64 >>> May 10 21:24:23 Updated: python-lxml-3.3.5-1.fc19.x86_64 >>> >>> I can also try to rollback and see... >>> >>> >>> I was right. >>> Against what to bugzilla? >>> This is a show stopper for fedora 19 ovirt users... >>> >>> >>> [root@tekkaman log]# vdsClient -s 0 getVdsCaps >>> Unexpected exception >>> >>> [root@tekkaman log]# yum downgrade python-lxml python-ethtool >>> Loaded plugins: fastestmirror, langpacks, refresh-packagekit, >>> versionlock >>> Dropbox | 951 B 00:00:00 >>> adobe-linux-x86_64 | 951 B 00:00:00 >>> fedora-virt-preview | 2.9 kB 00:00:00 >>> google-chrome | 951 B 00:00:00 >>> livna | 1.3 kB 00:00:00 >>> ovirt-3.3.3 | 2.9 kB 00:00:00 >>> ovirt-stable | 2.9 kB 00:00:00 >>> rpmfusion-free-updates | 3.3 kB 00:00:00 >>> rpmfusion-nonfree-updates | 3.3 kB 00:00:00 >>> updates/19/x86_64/metalink | 28 kB 00:00:00 >>> Loading mirror speeds from cached hostfile >>> * fedora: mirror.netcologne.de >>> * livna: rpm.livna.org >>> * rpmfusion-free: mirror.switch.ch >>> * rpmfusion-free-updates: mirror.switch.ch >>> * rpmfusion-nonfree: mirror.switch.ch >>> * rpmfusion-nonfree-updates: mirror.switch.ch >>> * updates: mirror.netcologne.de >>> Resolving Dependencies >>> --> Running transaction check >>> ---> Package python-ethtool.x86_64 0:0.8-1.fc19 will be a downgrade >>> ---> Package python-ethtool.x86_64 0:0.9-2.fc19 will be erased >>> ---> Package python-lxml.x86_64 0:3.2.1-1.fc19 will be a downgrade >>> ---> Package python-lxml.x86_64 0:3.3.5-1.fc19 will be erased >>> --> Finished Dependency Resolution >>> >>> Dependencies Resolved >>> >>> ====================================================================================================================================================== >>> >>> Package Arch Version Repository Size >>> ====================================================================================================================================================== >>> >>> Downgrading: >>> python-ethtool x86_64 0.8-1.fc19 fedora 32 k >>> python-lxml x86_64 3.2.1-1.fc19 fedora 752 k >>> >>> Transaction Summary >>> ====================================================================================================================================================== >>> >>> Downgrade 2 Packages >>> >>> Total download size: 785 k >>> Is this ok [y/d/N]: >>> Downloading packages: >>> (1/2): python-ethtool-0.8-1.fc19.x86_64.rpm | 32 kB 00:00:00 >>> (2/2): python-lxml-3.2.1-1.fc19.x86_64.rpm | 752 kB 00:00:02 >>> ------------------------------------------------------------------------------------------------------------------------------------------------------ >>> >>> Total 317 kB/s | 785 kB 00:00:02 >>> Running transaction check >>> Running transaction test >>> Transaction test succeeded >>> Running transaction >>> Installing : python-lxml-3.2.1-1.fc19.x86_64 1/4 >>> Installing : python-ethtool-0.8-1.fc19.x86_64 2/4 >>> Cleanup : python-lxml-3.3.5-1.fc19.x86_64 3/4 >>> Cleanup : python-ethtool-0.9-2.fc19.x86_64 4/4 >>> Verifying : python-ethtool-0.8-1.fc19.x86_64 1/4 >>> Verifying : python-lxml-3.2.1-1.fc19.x86_64 2/4 >>> Verifying : python-ethtool-0.9-2.fc19.x86_64 3/4 >>> Verifying : python-lxml-3.3.5-1.fc19.x86_64 4/4 >>> >>> Removed: >>> python-ethtool.x86_64 0:0.9-2.fc19 python-lxml.x86_64 0:3.3.5-1.fc19 >>> >>> Installed: >>> python-ethtool.x86_64 0:0.8-1.fc19 python-lxml.x86_64 0:3.2.1-1.fc19 >>> >>> Complete! >>> >>> [root@tekkaman log]# vdsClient -s 0 getVdsCaps >>> Unexpected exception >>> >>> >>> [root@tekkaman log]# systemctl restart vdsmd >>> >>> [root@tekkaman log]# systemctl status vdsmd >>> vdsmd.service - Virtual Desktop Server Manager >>> Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled) >>> Active: active (running) since Sun 2014-05-11 23:44:52 CEST; 16s ago >>> Process: 13935 ExecStopPost=/usr/libexec/vdsm/vdsmd_init_common.sh >>> --post-stop (code=exited, status=0/SUCCESS) >>> Process: 13939 ExecStartPre=/usr/libexec/vdsm/vdsmd_init_common.sh >>> --pre-start (code=exited, status=0/SUCCESS) >>> Main PID: 14003 (vdsm) >>> CGroup: name=systemd:/system/vdsmd.service >>> ├─14003 /usr/bin/python /usr/share/vdsm/vdsm >>> ├─14074 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc >>> 32 30 >>> ├─14081 rpc.statd --no-notify >>> ├─14103 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc >>> 34 32 >>> ├─14105 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc >>> 41 40 >>> ├─14106 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc >>> 48 46 >>> ├─14107 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc >>> 54 48 >>> ├─14108 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc >>> 41 40 >>> ├─14121 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc >>> 50 41 >>> ├─14123 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc >>> 66 65 >>> ├─14125 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc >>> 71 50 >>> ├─14129 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc >>> 75 71 >>> ├─14131 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc >>> 81 75 >>> ├─14135 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc >>> 92 89 >>> ├─14137 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc >>> 75 65 >>> └─14138 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc >>> 89 75 >>> >>> May 11 23:44:53 tekkaman.localdomain.local vdsm[14003]: vdsm vds WARNING >>> Unable to load the json rpc server module. Please make sure it is >>> installed. >>> May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 >>> client >>> step 2 >>> May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 >>> parse_server_challenge() >>> May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 >>> ask_user_info() >>> May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 >>> client >>> step 2 >>> May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 >>> ask_user_info() >>> May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 >>> make_client_response() >>> May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 >>> client >>> step 3 >>> May 11 23:44:57 tekkaman.localdomain.local rpc.statd[14081]: Version >>> 1.2.7 >>> starting >>> May 11 23:44:57 tekkaman.localdomain.local rpc.statd[14081]: Flags: >>> TI-RPC >>> >>> [root@tekkaman log]# vdsClient -s 0 getVdsCaps >>> HBAInventory = {'FC': [], 'iSCSI': [{'InitiatorName': >>> 'iqn.1994-05.com.redhat:e6aa759a959'}]} >>> ISCSIInitiatorName = 'iqn.1994-05.com.redhat:e6aa759a959' >>> bondings = {'bond0': {'addr': '', >>> 'cfg': {}, >>> 'hwaddr': '9a:0f:68:19:0f:87', >>> 'ipv6addrs': [], >>> 'mtu': '1500', >>> 'netmask': '', >>> 'slaves': []}} >>> bridges = {';vdsmdummy;': {'addr': '', >>> 'cfg': {}, >>> 'gateway': '', >>> 'ipv6addrs': [], >>> 'ipv6gateway': '::', >>> 'mtu': '1500', >>> 'netmask': '', >>> 'ports': [], >>> 'stp': 'off'}, >>> 'ovirtmgmt': {'addr': '192.168.1.101', >>> 'cfg': {'BOOTPROTO': 'none', >>> 'DELAY': '0', >>> 'DEVICE': 'ovirtmgmt', >>> 'GATEWAY': '192.168.1.1', >>> 'IPADDR': '192.168.1.101', >>> 'NETMASK': '255.255.255.0', >>> 'NM_CONTROLLED': 'no', >>> 'ONBOOT': 'yes', >>> 'TYPE': 'Bridge'}, >>> 'gateway': '192.168.1.1', >>> 'ipv6addrs': ['fe80::92e6:baff:fec9:f1e1/64'], >>> 'ipv6gateway': '::', >>> 'mtu': '1500', >>> 'netmask': '255.255.255.0', >>> 'ports': ['p10p1'], >>> 'stp': 'off'}} >>> clusterLevels = ['3.0', '3.1', '3.2', '3.3', '3.4'] >>> cpuCores = '4' >>> cpuFlags = >>> 'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,pdpe1gb,rdtscp,lm,3dnowext,3dnow,constant_tsc,rep_good,nopl,nonstop_tsc,extd_apicid,pni,monitor,cx16,popcnt,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,abm,sse4a,misalignsse,3dnowprefetch,osvw,ibs,skinit,wdt,hw_pstate,npt,lbrv,svm_lock,nrip_save,model_athlon,model_Opteron_G3,model_Opteron_G1,model_phenom,model_Opteron_G2' >>> >>> cpuModel = 'AMD Athlon(tm) II X4 630 Processor' >>> cpuSockets = '1' >>> cpuSpeed = '2800.000' >>> cpuThreads = '4' >>> emulatedMachines = ['pc', >>> 'pc-q35-1.4', >>> 'pc-q35-1.5', >>> 'q35', >>> 'isapc', >>> 'pc-0.10', >>> 'pc-0.11', >>> 'pc-0.12', >>> 'pc-0.13', >>> 'pc-0.14', >>> 'pc-0.15', >>> 'pc-1.0', >>> 'pc-1.1', >>> 'pc-1.2', >>> 'pc-1.3', >>> 'pc-i440fx-1.4', >>> 'pc-i440fx-1.5', >>> 'none'] >>> guestOverhead = '65' >>> hooks = {} >>> kvmEnabled = 'true' >>> lastClient = '192.168.1.101' >>> lastClientIface = 'ovirtmgmt' >>> management_ip = '0.0.0.0' >>> memSize = '16048' >>> netConfigDirty = 'False' >>> networks = {'ovirtmgmt': {'addr': '192.168.1.101', >>> 'bridged': True, >>> 'cfg': {'BOOTPROTO': 'none', >>> 'DELAY': '0', >>> 'DEVICE': 'ovirtmgmt', >>> 'GATEWAY': '192.168.1.1', >>> 'IPADDR': '192.168.1.101', >>> 'NETMASK': '255.255.255.0', >>> 'NM_CONTROLLED': 'no', >>> 'ONBOOT': 'yes', >>> 'TYPE': 'Bridge'}, >>> 'gateway': '192.168.1.1', >>> 'iface': 'ovirtmgmt', >>> 'ipv6addrs': ['fe80::92e6:baff:fec9:f1e1/64'], >>> 'ipv6gateway': '::', >>> 'mtu': '1500', >>> 'netmask': '255.255.255.0', >>> 'ports': ['p10p1'], >>> 'stp': 'off'}} >>> nics = {'p10p1': {'addr': '', >>> 'cfg': {'BRIDGE': 'ovirtmgmt', >>> 'DEVICE': 'p10p1', >>> 'HWADDR': '90:e6:ba:c9:f1:e1', >>> 'NM_CONTROLLED': 'no', >>> 'ONBOOT': 'yes'}, >>> 'hwaddr': '90:e6:ba:c9:f1:e1', >>> 'ipv6addrs': ['fe80::92e6:baff:fec9:f1e1/64'], >>> 'mtu': '1500', >>> 'netmask': '', >>> 'speed': 100}} >>> operatingSystem = {'name': 'Fedora', 'release': '8', 'version': '19'} >>> packages2 = {'kernel': {'buildtime': 1398276657.0, >>> 'release': '100.fc19.x86_64', >>> 'version': '3.13.11'}, >>> 'libvirt': {'buildtime': 1387094943, >>> 'release': '1.fc19', >>> 'version': '1.1.3.2'}, >>> 'mom': {'buildtime': 1391183561, 'release': '1.fc19', 'version': >>> '0.4.0'}, >>> 'qemu-img': {'buildtime': 1384762225, >>> 'release': '2.fc19', >>> 'version': '1.6.1'}, >>> 'qemu-kvm': {'buildtime': 1384762225, >>> 'release': '2.fc19', >>> 'version': '1.6.1'}, >>> 'spice-server': {'buildtime': 1383130020, >>> 'release': '3.fc19', >>> 'version': '0.12.4'}, >>> 'vdsm': {'buildtime': 1395804204, 'release': '0.fc19', 'version': >>> '4.14.6'}} >>> reservedMem = '321' >>> rngSources = ['random'] >>> software_revision = '0' >>> software_version = '4.14' >>> supportedENGINEs = ['3.0', '3.1', '3.2', '3.3', '3.4'] >>> supportedProtocols = ['2.2', '2.3'] >>> uuid = 'E0E1001E-8C00-002A-6F9A-90E6BAC9F1E1' >>> version_name = 'Snow Man' >>> vlans = {} >>> vmTypes = ['kvm'] >>> >>> And I'm now able to start and connect to my VM again. >>> >>> HIH, >>> Gianluca >>> >>> >>> >>> _______________________________________________ >>> Devel mailing list >>> Devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >> _______________________________________________ >> Devel mailing list >> Devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> > > We have a higher version of VDSM as well available for F19, in case you would like to test: https://admin.fedoraproject.org/updates/vdsm-4.14.8.1-0.fc19 Karmas are welcome! -- Cheers Douglas

1 0

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

Vdsm patches need review and merge
by Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) 16 May '14

16 May '14

--_000_08AA403C8399104A89AF710307FA78AE24404869G5W2743americas_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Martin, Could you help to review these numa vdsm patches: http://gerrit.ovirt.org/#/c/27399/ http://gerrit.ovirt.org/#/c/27090/ http://gerrit.ovirt.org/#/c/27403/ http://gerrit.ovirt.org/#/c/26876/ You had already reviewed some of the patches, but after that I modified the= transferred data format because of the xmlrpc limitations. So could you pl= ease review them again? Hi Dan, I have modified your comments for some of the above patches. Could you plea= se take a look and merge those if no more comments? Thanks & Best Regards Shi, Xiao-Lei (Bruce) Hewlett-Packard Co., Ltd. HP Servers Core Platform Software China Telephone +86 23 65683093 Mobile +86 18696583447 Email xiao-lei.shi(a)hp.com<mailto:shiguo.li@hp.com> --_000_08AA403C8399104A89AF710307FA78AE24404869G5W2743americas_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Hi Martin,<o:p></o:p> Could you help to review these numa vdsm patches:<o:= p></o:p> <a href=3D"http://gerrit.ovirt.org/#/c/27399/">http:= //gerrit.ovirt.org/#/c/27399/</a><o:p></o:p> <a href=3D"http://gerrit.ovirt.org/#/c/27090/">http:= //gerrit.ovirt.org/#/c/27090/</a><o:p></o:p> <a href=3D"http://gerrit.ovirt.org/#/c/27403/">http:= //gerrit.ovirt.org/#/c/27403/</a><o:p></o:p> <a href=3D"http://gerrit.ovirt.org/#/c/26876/">http:= //gerrit.ovirt.org/#/c/26876/</a><o:p></o:p> You had already reviewed some of the patches, but af= ter that I modified the transferred data format because of the xmlrpc limit= ations. So could you please review them again?<o:p></o:p> <o:p> </o:p> Hi Dan,<o:p></o:p> I have modified your comments for some of the above = patches. Could you please take a look and merge those if no more comments?<= o:p></o:p> <o:p> </o:p> Thanks & Best Regards<o:p></o:p> Shi, Xiao-Lei (Bruce)<o:p></o:p> <o:p> </o:p> Hewlett-Packard Co., Ltd. HP Servers Core Platform Software China <o:p></o:p> Telephone +86= 23 65683093<o:p></o:p> Mobile +86 18696583447<o:p></o:p><= /span> Email </b= ><a href=3D"mailto:shiguo.li@hp.com"><span= style=3D"color:blue">xiao-lei.shi(a)hp.com</a><o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_08AA403C8399104A89AF710307FA78AE24404869G5W2743americas_--

4 5

Re: [ovirt-devel] [vdsm] pep8 issue
by Dan Kenigsberg 15 May '14

15 May '14

On Tue, May 13, 2014 at 05:22:15PM -0300, Amador Pahim wrote: > Building vdsm/master in F20, I've got: > > ./vdsm/virt/migration.py:223:19: E225 missing whitespace around operator > > In vdsm/virt/migration.py: > > 218 e.err = (libvirt.VIR_ERR_OPERATION_ABORTED, # error code$ > 219 libvirt.VIR_FROM_QEMU, # error > domain$ > 220 'operation aborted', # error > message$ > 221 libvirt.VIR_ERR_WARNING, # error > level$ > 222 '', '', '', # str1, str2, > str3,$ > 223 -1, -1) # int1, int2$ > 224 raise e$ > > pep8 is not accepting negative integer. Instead, it is handling the > minus sign as an operator. Quick workaround is change -1 to int(-1). > Is this a known? Now it is ;-) > > I'm using python-pep8-1.5.4-1.fc20.noarch It seems like a bug in pep8 tool, and I see that it does not reproduce with v1.5.6 thereof. I'm adding Matthias who may agree to backport the fix to Fedora 20 (or upgrade completely to 1.5.6)

3 6

spacing fix with PatternFly and tables
by Greg Sheremeta 15 May '14

15 May '14

Hi, With the PatternFly look and feel patch applied, GWT's spacing attribute is no longer reliable. When GWT renders a table with this, it puts "cellspacing='10'" into the table. This no longer works, probably because we changed to border-box model. The alternative: .some-table { border-spacing: 10px; border-collapse: separate; } Greg Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gshereme(a)redhat.com

1 1

GFS2 mount via symlink problem
by Enrico Tagliavini 15 May '14

15 May '14

Hi, this issues i described on Red Hat bugzilla entry #888711 [1], but I'll recap here since there is come confusion (mostly my fault, sorry!) in the bug. System setup: CentOS 6.5 fully up to date SGI IS5000 SAS storage with 2 servers connected oVirt is 3.4.0 The Storage configured in oVirt is PosixFS, vfs type is gfs2 gfs2 is on top of CLVM Red Hat Cluster Manager (cman) is used to manage CLVM The issue is summarized by: [root@fionn-virt1 ~]# grep virtstorage /etc/fstab /dev/mapper/vg_is5000-lv_virtstorage /gfs2/virtstorage gfs2 noatime,nodiratime,nobarrier 0 0 [root@fionn-virt1 ~]# grep virtstorage /proc/mounts /dev/dm-13 /gfs2/virtstorage gfs2 rw,seclabel,noatime,nodiratime,hostdata=jid=0,nobarrier 0 0 /dev/dm-13 /rhev/data-center/mnt/_dev_mapper_vg__is5000-lv__virtstorage gfs2 rw,seclabel,noatime,nodiratime,hostdata=jid=0,nobarrier 0 0 [root@fionn-virt1 ~]# grep virtstorage /etc/mtab /dev/mapper/vg_is5000-lv_virtstorage /gfs2/virtstorage gfs2 rw,seclabel,noatime,nodiratime,hostdata=jid=0,nobarrier 0 0 /dev/mapper/vg_is5000-lv_virtstorage /rhev/data-center/mnt/_dev_mapper_vg__is5000-lv__virtstorage gfs2 rw,seclabel,noatime,nodiratime,hostdata=jid=0,nobarrier 0 0 The storage is mounted twice, first by the gfs2 init script and then by ovirt. As you can see even if both ovirt and gfs2 init script used the /dev/mapper/name symlink, in proc mounts there is the real device specified, the one the symlink is pointing to. I have no clue why only GFS2 does that (at least ext* FS are not, didn't checked anything else TBO, I have only ext* FS on other LVM volumes on the same system). In this case oVirt fails to check if the FS is mounted, since there is no entry in /proc/mounts matching the device name specified (the /dev/mapper/name one). I my example above I already applied a fix for that, so it is actually working. I've submitted a fix to ovirt gerrit, see [2], [3] and [4] (the latter is a unit test for checking gfs2). Note that [2] alone is not correct, it needs [3] as well to not break some other setup. Dan Kenigsberg of Red Hat suggested to move the discussion here, since this is a weird issue (why just GFS2 resolves the symlink?). I'm looking for advise, comments to the fix I proposed, but also about if this is actually the better fix? Like fixing GFS2 in the first place. That said I still think this should be handled by ovirt. It doesn't really matter if in /proc/mounts you have the symlink or the real device, it is the same mount Kind regards Enrico [1] https://bugzilla.redhat.com/show_bug.cgi?id=888711 [2] http://gerrit.ovirt.org/27321 [3] http://gerrit.ovirt.org/27425 [4] http://gerrit.ovirt.org/27514

2 2

limiting gwt compiler threads to 1
by Greg Sheremeta 15 May '14

15 May '14

Hi, On Fedora 20, I sometimes get GWT compiler crashes due to OutOfMemory. So I tried limiting to 1 thread like so: make clean install-dev PREFIX=$HOME/ovirt-engine DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=gecko1_8,safari" BUILD_UT=0 DEV_EXTRA_BUILD_FLAGS="-Dgwt.jjs.maxThreads=1 -Dgwt.jjs.permutationWorkerFactory=com.google.gwt.dev.ThreadedPermutationWorkerFactory" When the two compiler threads spawn, they seem to fire at the same time. [INFO] Compiling 2 permutations [INFO] Compiling permutation 0... [INFO] Compiling permutation 1... I would expect there to be a delay while 1 waits for 0: [INFO] Compiling 2 permutations [INFO] Compiling permutation 0... <30 second pause...> <done> [INFO] Compiling permutation 1... <30 second pause...> <done> Do I have the options wrong? Greg Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gshereme(a)redhat.com

3 4

vdsm sync meeting minutes May 13, 2014
by danken＠redhat.com 15 May '14

15 May '14

Vdsm sync call May 13, 2014 =========================== (Join us every other week, 14:30 GMT, on https://bluejeans.com/35386075901 or https://www.intercallonline.com/listNumbersByCode.action?confCode=353860759… ) =========================== - We had a long descussion about multiple graphic devices http://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:gr… - fromani to figure out whether libvirt intends to provide an "alias" for graphics devices. Without it, it would be next-to-impossible to support multiple spice devices. It's already cumbersome to tell spice from vnc devices. - On input, Vdsm must accept both legacy display definitions (in vm.conf) and new-style ones (in vm.conf['devices']). If both exist, legacy ones are to be ignored. - writeable floppies. We believe that they were never used. Currently, vdsm makes floppies writable based on the writability of their filesystem imagea, and checks it in an unsafe manner. So we intend to make all floppies read-only. Actually, it would be nicer to expose a "readonly" flag, so that the client can use in case it really needs to write on the floppy (such as for saving Doom I game state). - live merge Saggi to review Adam's patches, and see if their use of task id is acceptable to him, and would follow the devel(a)ovirt.org thread on the matter. I'm still worried about Engine trusting the vdsm mapping of taskid to (vmid,volumeid), as Vdsm can crash and disappear. - unified network persistence. recently, unified persistence has become the default on the master branch http://gerrit.ovirt.org/25784 this may cause breakage to post-boot network connectivity, in case vdsm fails to start. - To avoid this fragility, we plan to have a leaner standalone service to configure networking on boot. - As a stopgap measure, the management network would be set as ONBOOT=yes, so that most setup would keep their connectivity. please report other problems! - ioprocess integration There's a worry regarding the path of replacing remote-file-handler with ioprocess. Currently, ioprocess is mimicking rfh semantics, while it is more reasonable to align with the future, and make the current rfh implementation mimick ioprocess. When network decided to move away from ifcfg to iproute2, we refactor the code to support both (with configurators), implemented iproute2, and only recently - moved to use it by default. This path ensures that we're not stuck with a convoluted code that matches no implementation. Have I forgotten anything? Dan.

2 1

ovirt-engine on F20
by Sandro Bonazzola 14 May '14

14 May '14

Hi, I'm looking at Bug 1055604 - "Failed to execute stage 'Setup validation': Cannot find Jboss at /usr/share/jboss-as" while running engine-setup on Fedora 20 I haven't seen news about wildfly support on engine side so I'm thinking about workarounds. What about providing jboss-as-7.1.1-11 for F20 as we do for el6? BTW, Juan, can you push spec file used for jboss-as to releng-tools repo? http://resources.ovirt.org/pub/ovirt-3.4-snapshot-static/rpm/el6/x86_64/jbo… If it can conflict somehow with wildfly, what about having it in /opt and configure the engine for using jboss from there? Comments? -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1

Re: [ovirt-devel] oVirt Node ISO rpm-wrapper update
by Sandro Bonazzola 14 May '14

14 May '14

Il 12/05/2014 13:00, Fabian Deutsch ha scritto: > Hey, > > the "wrapper rpm" I am going to talk about is an rpm which contains the > Node ISO image which can be used easily with oVirt Engine. > yum can be used to update this rpm and retrieve the latest oVirt Node > iso for easy consumption. > > For some time we did not deliver Node for Engine in a wrapper rpm > because a lot of things have changed (see below for the full story). > > To get this working again I've been cleaning up the repo and the > contained spec. > > Th repo layout is now: > node-3.0 branch: > Builds the base image from scratch > > ovirt-3.4 branch: > Builds the iso for Engine using edit-node and the base image > > Open issues: A repo file needs to be generated on each build which > contains all the relevant oVirt repositories. > > Sandro, do you have an idea how we can retrieve all list of all relevant > oVirt repositories using some curl oneliner? No, no curl onliner available for that. If you need one, we can provide it. > The repositories are needed by edit-node to pull in the dependencies of > ovirt-node-plugin-vdsm (vdsm, gluster, ...). > > The changes are _slightly_ tested, and once they are in a better shape > we can update Jenkins to use these repos to build the image and rpm for > Engine. > > > Technical background story: > The problem was that the basic way of how the oVirt Node for Engine ISO > was build was dramatically changed. > > Originally the vdsm packages were part of Node's build process. > You build the Node and it was usable with Engine. > > Now - After we introduced plugins, vdsm was migrated into a plugin > (ovirt-node-plugin-vdsm) and the plugin is not part of Node's build > process. ISOs we build these days do not contain vdsm specific bits and > are called "base images". > So if you build Node these days, it is _not_ usable with Engine. > Don't Panic. > > The ovirt-node-plugin-vdsm is added to the "base image" in a second step > using edit-node. This process is now used in ovirt-3.4 branch, where > also the spec file for the wrapper-rpm resides. > > - fabian > -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1

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

14 May '14

Hi, We're going to start composing oVirt 3.4.2 RC on 2014-05-27 08:00 UTC from 3.4 branches. The bug tracker [1] shows no blocking bugs for the release There are still 75 bugs [2] targeted to 3.4.2. Excluding node and documentation bugs we still have 47 bugs [3] targeted to 3.4.2. Maintainers / Assignee: - Please add the bugs to the tracker if you think that 3.4.2 should not be released without them fixed. - Please update the target to any next release for bugs that won't be in 3.4.2: 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] http://bugzilla.redhat.com/1095370 [2] http://red.ht/1oqLLlr [3] http://red.ht/1nIAZXO [4] http://www.ovirt.org/OVirt_3.4.2_Release_Notes [5] http://www.ovirt.org/Testing/oVirt_3.4.2_Testing Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

vdsm disabling logical volumes
by Jiri Moskovcak 14 May '14

14 May '14

Greetings vdsm developers! While working on adding ISCSI support to the hosted engine tools, I ran into a problem with vdms. It seems that when stopped vdsm deactivates ALL logical volumes in it's volume group and when it starts it reactivates only specific logical volumes. This is a problem for hosted engine tools as they create logical volumes in the same volume group and when vdsm deactivates the LVs the hosted engine tools don't have a way to reactivate it, because the services drop the root permissions and are running as vdsm and apparently only root can activate LVs. So far the only suitable solution seems to be to change vdsm to only deactivate/activate it's own LVs. I would be grateful for any hints. Thank you, Jirka

6 26

latest python-lxml python-ethtool break VDSM on f19
by Roy Golan 14 May '14

14 May '14

This is a multi-part message in MIME format. --------------020703020706020607050801 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit FYI and please guide Gianluca against what to open a BZ -------- Original Message -------- Subject: Re: [ovirt-users] getVdsCapabilites unexpected exception [was: Re: AIO 3.4 on fedora 19 initial errors before coming up] Date: Sun, 11 May 2014 23:49:06 +0200 From: Gianluca Cecchi <gianluca.cecchi(a)gmail.com> To: Roy Golan <rgolan(a)redhat.com> CC: users <users(a)ovirt.org> On Sun, May 11, 2014 at 8:41 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com <mailto:gianluca.cecchi@gmail.com>> wrote: On Sun, May 11, 2014 at 8:18 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com <mailto:gianluca.cecchi@gmail.com>> wrote: On Sun, May 11, 2014 at 4:10 PM, Roy Golan <rgolan(a)redhat.com <mailto:rgolan@redhat.com>> wrote: The vm will stay in "Waiting.." as the getVdsCaps is failing and the monitoring of Vms will not take place. need to fix this "Unexpected error" first. is it a matter of ssl enabled configuration for host communication? i.e. can you try vdsClient -s 0 getVdsCaps ? _______________________________________________ Users mailing list Users(a)ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users I didn't change anything on this server. It is an all-in-one config so both engine and vdsm host are on it. Yesterday and every previous day I was able to start the system and start the VM; I only applied the yum update command yeseterday (with --exclude=sos due to the opened bug) and then I made shutdown of the system. Today after startup I got this problem. [root@tekkaman vdsm]# vdsClient -s 0 getVdsCaps Unexpected exception it seems the error in vdsm.log when I run the command above is of this type: Thread-25::ERROR::2014-05-11 20:18:02,202::BindingXMLRPC::1086::vds::(wrapper) unexpected error Traceback (most recent call last): File "/usr/share/vdsm/BindingXMLRPC.py", line 1070, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/BindingXMLRPC.py", line 393, in getCapabilities ret = api.getCapabilities() File "/usr/share/vdsm/API.py", line 1185, in getCapabilities c = caps.get() File "/usr/share/vdsm/caps.py", line 369, in get caps.update(netinfo.get()) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 557, in get netAttr.get('qosOutbound')) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 487, in _getNetInfo ipv4addr, ipv4netmask, ipv6addrs = getIpInfo(iface) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 317, in getIpInfo ipv6addrs = devInfo.get_ipv6_addresses() SystemError: error return without exception set Based on above errors, I think that for some reason these two python related packages that were updated yesterday are causing some problems with vdsm. Can you confirm that you can run ok the 3.4 vdsm with those? vdsm-4.14.6-0.fc19.x86_64 May 10 21:24:23 Updated: python-ethtool-0.9-2.fc19.x86_64 May 10 21:24:23 Updated: python-lxml-3.3.5-1.fc19.x86_64 I can also try to rollback and see... I was right. Against what to bugzilla? This is a show stopper for fedora 19 ovirt users... [root@tekkaman log]# vdsClient -s 0 getVdsCaps Unexpected exception [root@tekkaman log]# yum downgrade python-lxml python-ethtool Loaded plugins: fastestmirror, langpacks, refresh-packagekit, versionlock Dropbox | 951 B 00:00:00 adobe-linux-x86_64 | 951 B 00:00:00 fedora-virt-preview | 2.9 kB 00:00:00 google-chrome | 951 B 00:00:00 livna | 1.3 kB 00:00:00 ovirt-3.3.3 | 2.9 kB 00:00:00 ovirt-stable | 2.9 kB 00:00:00 rpmfusion-free-updates | 3.3 kB 00:00:00 rpmfusion-nonfree-updates | 3.3 kB 00:00:00 updates/19/x86_64/metalink | 28 kB 00:00:00 Loading mirror speeds from cached hostfile * fedora: mirror.netcologne.de <http://mirror.netcologne.de> * livna: rpm.livna.org <http://rpm.livna.org> * rpmfusion-free: mirror.switch.ch <http://mirror.switch.ch> * rpmfusion-free-updates: mirror.switch.ch <http://mirror.switch.ch> * rpmfusion-nonfree: mirror.switch.ch <http://mirror.switch.ch> * rpmfusion-nonfree-updates: mirror.switch.ch <http://mirror.switch.ch> * updates: mirror.netcologne.de <http://mirror.netcologne.de> Resolving Dependencies --> Running transaction check ---> Package python-ethtool.x86_64 0:0.8-1.fc19 will be a downgrade ---> Package python-ethtool.x86_64 0:0.9-2.fc19 will be erased ---> Package python-lxml.x86_64 0:3.2.1-1.fc19 will be a downgrade ---> Package python-lxml.x86_64 0:3.3.5-1.fc19 will be erased --> Finished Dependency Resolution Dependencies Resolved ====================================================================================================================================================== Package Arch Version Repository Size ====================================================================================================================================================== Downgrading: python-ethtool x86_64 0.8-1.fc19 fedora 32 k python-lxml x86_64 3.2.1-1.fc19 fedora 752 k Transaction Summary ====================================================================================================================================================== Downgrade 2 Packages Total download size: 785 k Is this ok [y/d/N]: Downloading packages: (1/2): python-ethtool-0.8-1.fc19.x86_64.rpm | 32 kB 00:00:00 (2/2): python-lxml-3.2.1-1.fc19.x86_64.rpm | 752 kB 00:00:02 ------------------------------------------------------------------------------------------------------------------------------------------------------ Total 317 kB/s | 785 kB 00:00:02 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : python-lxml-3.2.1-1.fc19.x86_64 1/4 Installing : python-ethtool-0.8-1.fc19.x86_64 2/4 Cleanup : python-lxml-3.3.5-1.fc19.x86_64 3/4 Cleanup : python-ethtool-0.9-2.fc19.x86_64 4/4 Verifying : python-ethtool-0.8-1.fc19.x86_64 1/4 Verifying : python-lxml-3.2.1-1.fc19.x86_64 2/4 Verifying : python-ethtool-0.9-2.fc19.x86_64 3/4 Verifying : python-lxml-3.3.5-1.fc19.x86_64 4/4 Removed: python-ethtool.x86_64 0:0.9-2.fc19 python-lxml.x86_64 0:3.3.5-1.fc19 Installed: python-ethtool.x86_64 0:0.8-1.fc19 python-lxml.x86_64 0:3.2.1-1.fc19 Complete! [root@tekkaman log]# vdsClient -s 0 getVdsCaps Unexpected exception [root@tekkaman log]# systemctl restart vdsmd [root@tekkaman log]# systemctl status vdsmd vdsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled) Active: active (running) since Sun 2014-05-11 23:44:52 CEST; 16s ago Process: 13935 ExecStopPost=/usr/libexec/vdsm/vdsmd_init_common.sh --post-stop (code=exited, status=0/SUCCESS) Process: 13939 ExecStartPre=/usr/libexec/vdsm/vdsmd_init_common.sh --pre-start (code=exited, status=0/SUCCESS) Main PID: 14003 (vdsm) CGroup: name=systemd:/system/vdsmd.service ├─14003 /usr/bin/python /usr/share/vdsm/vdsm ├─14074 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 32 30 ├─14081 rpc.statd --no-notify ├─14103 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 34 32 ├─14105 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 41 40 ├─14106 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 48 46 ├─14107 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 54 48 ├─14108 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 41 40 ├─14121 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 50 41 ├─14123 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 66 65 ├─14125 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 71 50 ├─14129 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 75 71 ├─14131 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 81 75 ├─14135 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 92 89 ├─14137 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 75 65 └─14138 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 89 75 May 11 23:44:53 tekkaman.localdomain.local vdsm[14003]: vdsm vds WARNING Unable to load the json rpc server module. Please make sure it is installed. May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 client step 2 May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 parse_server_challenge() May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 ask_user_info() May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 client step 2 May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 ask_user_info() May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 make_client_response() May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 client step 3 May 11 23:44:57 tekkaman.localdomain.local rpc.statd[14081]: Version 1.2.7 starting May 11 23:44:57 tekkaman.localdomain.local rpc.statd[14081]: Flags: TI-RPC [root@tekkaman log]# vdsClient -s 0 getVdsCaps HBAInventory = {'FC': [], 'iSCSI': [{'InitiatorName': 'iqn.1994-05.com.redhat:e6aa759a959'}]} ISCSIInitiatorName = 'iqn.1994-05.com.redhat:e6aa759a959' bondings = {'bond0': {'addr': '', 'cfg': {}, 'hwaddr': '9a:0f:68:19:0f:87', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'slaves': []}} bridges = {';vdsmdummy;': {'addr': '', 'cfg': {}, 'gateway': '', 'ipv6addrs': [], 'ipv6gateway': '::', 'mtu': '1500', 'netmask': '', 'ports': [], 'stp': 'off'}, 'ovirtmgmt': {'addr': '192.168.1.101', 'cfg': {'BOOTPROTO': 'none', 'DELAY': '0', 'DEVICE': 'ovirtmgmt', 'GATEWAY': '192.168.1.1', 'IPADDR': '192.168.1.101', 'NETMASK': '255.255.255.0', 'NM_CONTROLLED': 'no', 'ONBOOT': 'yes', 'TYPE': 'Bridge'}, 'gateway': '192.168.1.1', 'ipv6addrs': ['fe80::92e6:baff:fec9:f1e1/64'], 'ipv6gateway': '::', 'mtu': '1500', 'netmask': '255.255.255.0', 'ports': ['p10p1'], 'stp': 'off'}} clusterLevels = ['3.0', '3.1', '3.2', '3.3', '3.4'] cpuCores = '4' cpuFlags = 'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,pdpe1gb,rdtscp,lm,3dnowext,3dnow,constant_tsc,rep_good,nopl,nonstop_tsc,extd_apicid,pni,monitor,cx16,popcnt,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,abm,sse4a,misalignsse,3dnowprefetch,osvw,ibs,skinit,wdt,hw_pstate,npt,lbrv,svm_lock,nrip_save,model_athlon,model_Opteron_G3,model_Opteron_G1,model_phenom,model_Opteron_G2' cpuModel = 'AMD Athlon(tm) II X4 630 Processor' cpuSockets = '1' cpuSpeed = '2800.000' cpuThreads = '4' emulatedMachines = ['pc', 'pc-q35-1.4', 'pc-q35-1.5', 'q35', 'isapc', 'pc-0.10', 'pc-0.11', 'pc-0.12', 'pc-0.13', 'pc-0.14', 'pc-0.15', 'pc-1.0', 'pc-1.1', 'pc-1.2', 'pc-1.3', 'pc-i440fx-1.4', 'pc-i440fx-1.5', 'none'] guestOverhead = '65' hooks = {} kvmEnabled = 'true' lastClient = '192.168.1.101' lastClientIface = 'ovirtmgmt' management_ip = '0.0.0.0' memSize = '16048' netConfigDirty = 'False' networks = {'ovirtmgmt': {'addr': '192.168.1.101', 'bridged': True, 'cfg': {'BOOTPROTO': 'none', 'DELAY': '0', 'DEVICE': 'ovirtmgmt', 'GATEWAY': '192.168.1.1', 'IPADDR': '192.168.1.101', 'NETMASK': '255.255.255.0', 'NM_CONTROLLED': 'no', 'ONBOOT': 'yes', 'TYPE': 'Bridge'}, 'gateway': '192.168.1.1', 'iface': 'ovirtmgmt', 'ipv6addrs': ['fe80::92e6:baff:fec9:f1e1/64'], 'ipv6gateway': '::', 'mtu': '1500', 'netmask': '255.255.255.0', 'ports': ['p10p1'], 'stp': 'off'}} nics = {'p10p1': {'addr': '', 'cfg': {'BRIDGE': 'ovirtmgmt', 'DEVICE': 'p10p1', 'HWADDR': '90:e6:ba:c9:f1:e1', 'NM_CONTROLLED': 'no', 'ONBOOT': 'yes'}, 'hwaddr': '90:e6:ba:c9:f1:e1', 'ipv6addrs': ['fe80::92e6:baff:fec9:f1e1/64'], 'mtu': '1500', 'netmask': '', 'speed': 100}} operatingSystem = {'name': 'Fedora', 'release': '8', 'version': '19'} packages2 = {'kernel': {'buildtime': 1398276657.0, 'release': '100.fc19.x86_64', 'version': '3.13.11'}, 'libvirt': {'buildtime': 1387094943, 'release': '1.fc19', 'version': '1.1.3.2'}, 'mom': {'buildtime': 1391183561, 'release': '1.fc19', 'version': '0.4.0'}, 'qemu-img': {'buildtime': 1384762225, 'release': '2.fc19', 'version': '1.6.1'}, 'qemu-kvm': {'buildtime': 1384762225, 'release': '2.fc19', 'version': '1.6.1'}, 'spice-server': {'buildtime': 1383130020, 'release': '3.fc19', 'version': '0.12.4'}, 'vdsm': {'buildtime': 1395804204, 'release': '0.fc19', 'version': '4.14.6'}} reservedMem = '321' rngSources = ['random'] software_revision = '0' software_version = '4.14' supportedENGINEs = ['3.0', '3.1', '3.2', '3.3', '3.4'] supportedProtocols = ['2.2', '2.3'] uuid = 'E0E1001E-8C00-002A-6F9A-90E6BAC9F1E1' version_name = 'Snow Man' vlans = {} vmTypes = ['kvm'] And I'm now able to start and connect to my VM again. HIH, Gianluca --------------020703020706020607050801 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> FYI and please guide Gianluca against what to open a BZ <div class="moz-forward-container"> -------- Original Message -------- <table class="moz-email-headers-table" border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <th nowrap="nowrap" valign="BASELINE" align="RIGHT">Subject: </th> <td>Re: [ovirt-users] getVdsCapabilites unexpected exception [was: Re: AIO 3.4 on fedora 19 initial errors before coming up]</td> </tr> <tr> <th nowrap="nowrap" valign="BASELINE" align="RIGHT">Date: </th> <td>Sun, 11 May 2014 23:49:06 +0200</td> </tr> <tr> <th nowrap="nowrap" valign="BASELINE" align="RIGHT">From: </th> <td>Gianluca Cecchi <a class="moz-txt-link-rfc2396E" href="mailto:gianluca.cecchi@gmail.com"><gianluca.cecchi(a)gmail.com></a></td> </tr> <tr> <th nowrap="nowrap" valign="BASELINE" align="RIGHT">To: </th> <td>Roy Golan <a class="moz-txt-link-rfc2396E" href="mailto:rgolan@redhat.com"><rgolan(a)redhat.com></a></td> </tr> <tr> <th nowrap="nowrap" valign="BASELINE" align="RIGHT">CC: </th> <td>users <a class="moz-txt-link-rfc2396E" href="mailto:users@ovirt.org"><users(a)ovirt.org></a></td> </tr> </tbody> </table> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote">On Sun, May 11, 2014 at 8:41 PM, Gianluca Cecchi <<a moz-do-not-send="true" href="mailto:gianluca.cecchi@gmail.com" target="_blank">gianluca.cecchi(a)gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"> <div class="gmail_extra"> <div> <div class="h5"> <div class="gmail_quote">On Sun, May 11, 2014 at 8:18 PM, Gianluca Cecchi <<a moz-do-not-send="true" href="mailto:gianluca.cecchi@gmail.com" target="_blank">gianluca.cecchi(a)gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"> <div> <div class="gmail_extra"> <div class="gmail_quote">On Sun, May 11, 2014 at 4:10 PM, Roy Golan <<a moz-do-not-send="true" href="mailto:rgolan@redhat.com" target="_blank">rgolan(a)redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div bgcolor="#FFFFFF" text="#000000"> The vm will stay in "Waiting.." as the getVdsCaps is failing and the monitoring of Vms will not take place. need to fix this "Unexpected error" first. is it a matter of ssl enabled configuration for host communication? i.e. can you try vdsClient -s 0 getVdsCaps ? </div> _______________________________________________ Users mailing list <a moz-do-not-send="true" href="mailto:Users@ovirt.org" target="_blank">Users(a)ovirt.org</a> <a moz-do-not-send="true" href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a> </blockquote> </div> </div> </div> <div class="gmail_extra">I didn't change anything on this server. It is an all-in-one config so both engine and vdsm host are on it. </div> <div class="gmail_extra">Yesterday and every previous day I was able to start the system and start the VM; I only applied the yum update command yeseterday </div> <div class="gmail_extra">(with --exclude=sos due to the opened bug) and then I made shutdown of the system. </div> <div class="gmail_extra">Today after startup I got this problem. [root@tekkaman vdsm]# vdsClient -s 0 getVdsCaps Unexpected exception </div> <div class="gmail_extra">it seems the error in vdsm.log when I run the command above is of this type: Thread-25::ERROR::2014-05-11 20:18:02,202::BindingXMLRPC::1086::vds::(wrapper) unexpected error Traceback (most recent call last): File "/usr/share/vdsm/BindingXMLRPC.py", line 1070, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/BindingXMLRPC.py", line 393, in getCapabilities ret = api.getCapabilities() File "/usr/share/vdsm/API.py", line 1185, in getCapabilities c = caps.get() File "/usr/share/vdsm/caps.py", line 369, in get caps.update(netinfo.get()) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 557, in get netAttr.get('qosOutbound')) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 487, in _getNetInfo ipv4addr, ipv4netmask, ipv6addrs = getIpInfo(iface) File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 317, in getIpInfo ipv6addrs = devInfo.get_ipv6_addresses() SystemError: error return without exception set </div> </div> </blockquote> </div> </div> </div> Based on above errors, I think that for some reason these two python related packages that were updated yesterday are causing some problems with vdsm. Can you confirm that you can run ok the 3.4 vdsm with those? vdsm-4.14.6-0.fc19.x86_64 <div class=""> May 10 21:24:23 Updated: python-ethtool-0.9-2.fc19.x86_64 </div> May 10 21:24:23 Updated: python-lxml-3.3.5-1.fc19.x86_64 </div> <div class="gmail_extra">I can also try to rollback and see... </div> </div> </blockquote> </div> I was right. </div> <div class="gmail_extra">Against what to bugzilla? </div> <div class="gmail_extra">This is a show stopper for fedora 19 ovirt users... </div> <div class="gmail_extra"> [root@tekkaman log]# vdsClient -s 0 getVdsCaps Unexpected exception [root@tekkaman log]# yum downgrade python-lxml python-ethtool Loaded plugins: fastestmirror, langpacks, refresh-packagekit, versionlock Dropbox | 951 B 00:00:00 adobe-linux-x86_64 | 951 B 00:00:00 fedora-virt-preview | 2.9 kB 00:00:00 google-chrome | 951 B 00:00:00 livna | 1.3 kB 00:00:00 ovirt-3.3.3 | 2.9 kB 00:00:00 ovirt-stable | 2.9 kB 00:00:00 rpmfusion-free-updates | 3.3 kB 00:00:00 rpmfusion-nonfree-updates | 3.3 kB 00:00:00 updates/19/x86_64/metalink | 28 kB 00:00:00 Loading mirror speeds from cached hostfile * fedora: <a moz-do-not-send="true" href="http://mirror.netcologne.de">mirror.netcologne.de</a> * livna: <a moz-do-not-send="true" href="http://rpm.livna.org">rpm.livna.org</a> * rpmfusion-free: <a moz-do-not-send="true" href="http://mirror.switch.ch">mirror.switch.ch</a> * rpmfusion-free-updates: <a moz-do-not-send="true" href="http://mirror.switch.ch">mirror.switch.ch</a> * rpmfusion-nonfree: <a moz-do-not-send="true" href="http://mirror.switch.ch">mirror.switch.ch</a> * rpmfusion-nonfree-updates: <a moz-do-not-send="true" href="http://mirror.switch.ch">mirror.switch.ch</a> * updates: <a moz-do-not-send="true" href="http://mirror.netcologne.de">mirror.netcologne.de</a> Resolving Dependencies --> Running transaction check ---> Package python-ethtool.x86_64 0:0.8-1.fc19 will be a downgrade ---> Package python-ethtool.x86_64 0:0.9-2.fc19 will be erased ---> Package python-lxml.x86_64 0:3.2.1-1.fc19 will be a downgrade ---> Package python-lxml.x86_64 0:3.3.5-1.fc19 will be erased --> Finished Dependency Resolution Dependencies Resolved ====================================================================================================================================================== Package Arch Version Repository Size ====================================================================================================================================================== Downgrading: python-ethtool x86_64 0.8-1.fc19 fedora 32 k python-lxml x86_64 3.2.1-1.fc19 fedora 752 k Transaction Summary ====================================================================================================================================================== Downgrade 2 Packages Total download size: 785 k Is this ok [y/d/N]: Downloading packages: (1/2): python-ethtool-0.8-1.fc19.x86_64.rpm | 32 kB 00:00:00 (2/2): python-lxml-3.2.1-1.fc19.x86_64.rpm | 752 kB 00:00:02 ------------------------------------------------------------------------------------------------------------------------------------------------------ Total 317 kB/s | 785 kB 00:00:02 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : python-lxml-3.2.1-1.fc19.x86_64 1/4 Installing : python-ethtool-0.8-1.fc19.x86_64 2/4 Cleanup : python-lxml-3.3.5-1.fc19.x86_64 3/4 Cleanup : python-ethtool-0.9-2.fc19.x86_64 4/4 Verifying : python-ethtool-0.8-1.fc19.x86_64 1/4 Verifying : python-lxml-3.2.1-1.fc19.x86_64 2/4 Verifying : python-ethtool-0.9-2.fc19.x86_64 3/4 Verifying : python-lxml-3.3.5-1.fc19.x86_64 4/4 Removed: python-ethtool.x86_64 0:0.9-2.fc19 python-lxml.x86_64 0:3.3.5-1.fc19 Installed: python-ethtool.x86_64 0:0.8-1.fc19 python-lxml.x86_64 0:3.2.1-1.fc19 Complete! [root@tekkaman log]# vdsClient -s 0 getVdsCaps Unexpected exception [root@tekkaman log]# systemctl restart vdsmd [root@tekkaman log]# systemctl status vdsmd vdsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled) Active: active (running) since Sun 2014-05-11 23:44:52 CEST; 16s ago Process: 13935 ExecStopPost=/usr/libexec/vdsm/vdsmd_init_common.sh --post-stop (code=exited, status=0/SUCCESS) Process: 13939 ExecStartPre=/usr/libexec/vdsm/vdsmd_init_common.sh --pre-start (code=exited, status=0/SUCCESS) Main PID: 14003 (vdsm) CGroup: name=systemd:/system/vdsmd.service ├─14003 /usr/bin/python /usr/share/vdsm/vdsm ├─14074 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 32 30 ├─14081 rpc.statd --no-notify ├─14103 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 34 32 ├─14105 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 41 40 ├─14106 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 48 46 ├─14107 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 54 48 ├─14108 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 41 40 ├─14121 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 50 41 ├─14123 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 66 65 ├─14125 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 71 50 ├─14129 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 75 71 ├─14131 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 81 75 ├─14135 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 92 89 ├─14137 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 75 65 └─14138 /usr/bin/python /usr/share/vdsm/storage/remoteFileHandler.pyc 89 75 May 11 23:44:53 tekkaman.localdomain.local vdsm[14003]: vdsm vds WARNING Unable to load the json rpc server module. Please make sure it is installed. May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 client step 2 May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 parse_server_challenge() May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 ask_user_info() May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 client step 2 May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 ask_user_info() May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 make_client_response() May 11 23:44:53 tekkaman.localdomain.local python[14003]: DIGEST-MD5 client step 3 May 11 23:44:57 tekkaman.localdomain.local rpc.statd[14081]: Version 1.2.7 starting May 11 23:44:57 tekkaman.localdomain.local rpc.statd[14081]: Flags: TI-RPC [root@tekkaman log]# vdsClient -s 0 getVdsCaps HBAInventory = {'FC': [], 'iSCSI': [{'InitiatorName': 'iqn.1994-05.com.redhat:e6aa759a959'}]} ISCSIInitiatorName = 'iqn.1994-05.com.redhat:e6aa759a959' bondings = {'bond0': {'addr': '', 'cfg': {}, 'hwaddr': '9a:0f:68:19:0f:87', 'ipv6addrs': [], 'mtu': '1500', 'netmask': '', 'slaves': []}} bridges = {';vdsmdummy;': {'addr': '', 'cfg': {}, 'gateway': '', 'ipv6addrs': [], 'ipv6gateway': '::', 'mtu': '1500', 'netmask': '', 'ports': [], 'stp': 'off'}, 'ovirtmgmt': {'addr': '192.168.1.101', 'cfg': {'BOOTPROTO': 'none', 'DELAY': '0', 'DEVICE': 'ovirtmgmt', 'GATEWAY': '192.168.1.1', 'IPADDR': '192.168.1.101', 'NETMASK': '255.255.255.0', 'NM_CONTROLLED': 'no', 'ONBOOT': 'yes', 'TYPE': 'Bridge'}, 'gateway': '192.168.1.1', 'ipv6addrs': ['fe80::92e6:baff:fec9:f1e1/64'], 'ipv6gateway': '::', 'mtu': '1500', 'netmask': '255.255.255.0', 'ports': ['p10p1'], 'stp': 'off'}} clusterLevels = ['3.0', '3.1', '3.2', '3.3', '3.4'] cpuCores = '4' cpuFlags = 'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,pdpe1gb,rdtscp,lm,3dnowext,3dnow,constant_tsc,rep_good,nopl,nonstop_tsc,extd_apicid,pni,monitor,cx16,popcnt,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,abm,sse4a,misalignsse,3dnowprefetch,osvw,ibs,skinit,wdt,hw_pstate,npt,lbrv,svm_lock,nrip_save,model_athlon,model_Opteron_G3,model_Opteron_G1,model_phenom,model_Opteron_G2' cpuModel = 'AMD Athlon(tm) II X4 630 Processor' cpuSockets = '1' cpuSpeed = '2800.000' cpuThreads = '4' emulatedMachines = ['pc', 'pc-q35-1.4', 'pc-q35-1.5', 'q35', 'isapc', 'pc-0.10', 'pc-0.11', 'pc-0.12', 'pc-0.13', 'pc-0.14', 'pc-0.15', 'pc-1.0', 'pc-1.1', 'pc-1.2', 'pc-1.3', 'pc-i440fx-1.4', 'pc-i440fx-1.5', 'none'] guestOverhead = '65' hooks = {} kvmEnabled = 'true' lastClient = '192.168.1.101' lastClientIface = 'ovirtmgmt' management_ip = '0.0.0.0' memSize = '16048' netConfigDirty = 'False' networks = {'ovirtmgmt': {'addr': '192.168.1.101', 'bridged': True, 'cfg': {'BOOTPROTO': 'none', 'DELAY': '0', 'DEVICE': 'ovirtmgmt', 'GATEWAY': '192.168.1.1', 'IPADDR': '192.168.1.101', 'NETMASK': '255.255.255.0', 'NM_CONTROLLED': 'no', 'ONBOOT': 'yes', 'TYPE': 'Bridge'}, 'gateway': '192.168.1.1', 'iface': 'ovirtmgmt', 'ipv6addrs': ['fe80::92e6:baff:fec9:f1e1/64'], 'ipv6gateway': '::', 'mtu': '1500', 'netmask': '255.255.255.0', 'ports': ['p10p1'], 'stp': 'off'}} nics = {'p10p1': {'addr': '', 'cfg': {'BRIDGE': 'ovirtmgmt', 'DEVICE': 'p10p1', 'HWADDR': '90:e6:ba:c9:f1:e1', 'NM_CONTROLLED': 'no', 'ONBOOT': 'yes'}, 'hwaddr': '90:e6:ba:c9:f1:e1', 'ipv6addrs': ['fe80::92e6:baff:fec9:f1e1/64'], 'mtu': '1500', 'netmask': '', 'speed': 100}} operatingSystem = {'name': 'Fedora', 'release': '8', 'version': '19'} packages2 = {'kernel': {'buildtime': 1398276657.0, 'release': '100.fc19.x86_64', 'version': '3.13.11'}, 'libvirt': {'buildtime': 1387094943, 'release': '1.fc19', 'version': '1.1.3.2'}, 'mom': {'buildtime': 1391183561, 'release': '1.fc19', 'version': '0.4.0'}, 'qemu-img': {'buildtime': 1384762225, 'release': '2.fc19', 'version': '1.6.1'}, 'qemu-kvm': {'buildtime': 1384762225, 'release': '2.fc19', 'version': '1.6.1'}, 'spice-server': {'buildtime': 1383130020, 'release': '3.fc19', 'version': '0.12.4'}, 'vdsm': {'buildtime': 1395804204, 'release': '0.fc19', 'version': '4.14.6'}} reservedMem = '321' rngSources = ['random'] software_revision = '0' software_version = '4.14' supportedENGINEs = ['3.0', '3.1', '3.2', '3.3', '3.4'] supportedProtocols = ['2.2', '2.3'] uuid = 'E0E1001E-8C00-002A-6F9A-90E6BAC9F1E1' version_name = 'Snow Man' vlans = {} vmTypes = ['kvm'] </div> <div class="gmail_extra">And I'm now able to start and connect to my VM again. </div> <div class="gmail_extra"> HIH, Gianluca </div> </div> </div> </body> </html> --------------020703020706020607050801--

4 3

Sortable columns in UI
by Vojtech Szocs 14 May '14

14 May '14

------=_Part_4640012_120094896.1399991871152 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hey guys, oVirt UI has been missing column sort functionality for quite a while now, but here's some good news. I've just merged patch [1] that adds support for both server-side and client-side sorting of table columns. This patch adds the necessary infra/API; column sorting must be enabled per-column for given table, just like with column resizing. [1] http://gerrit.ovirt.org/#/c/25910/ Currently, only TextColumnWithTooltip (and its subclasses) support sorting, however this can easily be changed in future by having the column class extend SortableColumn. To enable sorting: // Enables server-side sorting via search query // ... SORTBY name ASC|DESC column.makeSortable("name"); // consider using shared constant -or- // Enables client-side sorting using comparator column.makeSortable(comparator); In order for server-side sorting to work properly, corresponding SearchableListModel must apply the search options while executing "Search" query. For example, in DataCenterListModel: @Override public boolean supportsServerSideSorting() { // Default is false return true; } @Override protected void syncSearch() { // Append "SORTBY" clause to search query String search = applySortOptions(getSearchString()); ... } If a model doesn't support server-side sorting, client-side sorting will be used as fall back (assuming a comparator was provided). In general, all main tab list models in WebAdmin utilize "Search" query, so we can enable server-side sorting for columns that exist within main tab tables. As for sub tabs (whose list models generally don't use "Search" query, but also don't support paging at the moment), these can simply use client-side sorting, i.e. reuse existing comparators defined in Linq class. PS: I've attached a screenshot depicting sorted column in action. Regards, Vojtech ------=_Part_4640012_120094896.1399991871152 Content-Type: image/png; name=sorted-column.png Content-Disposition: attachment; filename=sorted-column.png Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAALQAAACnCAYAAAC4j3YHAAAACXBIWXMAAAsTAAALEwEAmpwYAAAA B3RJTUUH3gUNDiIpMfRzFAAAGZdJREFUeJzt3XlcVdXC//HPOYBwFBQUUFIQTEUfkHKg6xPOYw5J kXWdbnYbsG6P1XPN1DQ1eyrU7OnavaXcX5mg3kckvQpqOOKAI45kmgoOCAKCosh44KzfH8iWg4Cc AaHder9eR8+e1lp7nS+bfTb7rKOZOHGiEEIghEB6tDQaDRqNRnkOKK+DfE0errr+szUYDEadKD0a Go0GIQQajQatVmvU9/I1ebia+s/Wy8uLsLCwBm7e79fMmTO5evUqWq0WKA+zl5cXf/rTn+jUqRO2 trYN3MLGqbS0lAsXLhAZGWnUf5rExETRs2fPBm7e79exY8f44osvjAL9/vvv4+Pj08At+224dOmS Uf/ZyjA3rIr+r3xq0b59+4Zqzm9ORV8ppxwN2RipXMW5YMVzGxubBm7Rb4eNjY1R/8lAN0LyjaD5 tA3dAEmyJhloSVVkoCVVqdM59IA/TleeN2vqQDdfb159aTidO7Src0Xrf0pg6Yp/E792semtvGfP odOs/HEHqddv0LKFI8P69eTPLw5TLtlYyhptbGg///wzO3fuJDs7G0dHR7p3786QIUOUPpo1axYA n3/+uUX1HDhwgJiYGIvLsTaTkhC/djHLPn2HjOxbTJ33DRcvp9d5272Hk0xuXGVHT59n/leraO3q zIblc+kV4Evk+p18H7XNonIrs7SNDe3ChQusWbMGZ2dnZs+eTadOndi9ezc7duywel1nzpyxepnW YPJVDs/H3Hhj3AhmL/6BiB93sGDaywCkpt/g65UbOXvhKgaDwM+3Pe+9+jyPtW5ldIQf8MfpxK9d XOv61YmK3YsQgonPDcKxmY6XQwZz5NQ5buflK+sUFesJX7OZ+EOnKSwqYUDvAP76egh2draUlpUx ZMJMWjo78V+Tg1m6YgP2TeyY8dZL9PDvVG0baytPX1rG0Inl5b0wog8ro7ez9OO/8O2qWC5eSscg BP/RyYuprwTj3a61SX1ccQnKVPv370cIwcCBA9HpdAwaNIjz58+Tn5//QJkV0zNnzgRQ/lpcefra tWts2bKFtLQ0hBB4eXkxZswYvvzyS6WcWbNmERYWhl6vZ+vWrSQlJVFcXExAQADPPfcctra2lJWV MXv2bJycnHj66afZuXMnb775ZrVlu7u7m7XvFcz6Xf1E1w4AnDqbosxb+G0Ux5IusGROKJ+8/zJH Tv7Kwm+jAIx+hVc8r2396ly+lgGAj2cbAFq7ubDumzlMe+MFZZ3wNZtZ/1MCoeNH8u6fn2Nr/FHW bd4HgO29a7t5+YWU6PVMn/Iimdm5/H1lTI1trK08O9vy8u7mF2Jna0vM9wv4+KtVnPolhWWfv8OS OW/w86+X+cfKTaZ1rgUyMzMBaN26/AfIxcWFWbNmERISYlZ5a9asISUlhalTp/L6669z5coVYmJi jG6VqHi+detWDhw4wDPPPENwcDCJiYns378fQLmuXlhYiK2tLfPmzauxbEuZdR3awaEJAPkFRcq8 v3/ytvK8RF8KwC8XrtRYhqnr594pPxLr7tVdnT33ThmCAv2w0WoJ+3Yt2/cfZ8JzA5V19PpS+gb6 08SufNevpmVZVF6JvpRh/Xpi38RO2Y/1W/fT9yl/Yr9fgJ2d6V1s7nXo/PzyPrKzs3toGVWXVzet 1+sBSEhIwM/Pj7lz52Jra2u0bsXzpKTyvuratStarZZ169Zx4sQJ+vfvr6xbWlpK9+7dsbW1rVPZ 5jAr0LfvhatF82bKvGNJF/j7yk2kpt+gzGAAQF9aVmMZpq7f0tmJzBu3KCwuoZnOodp17tw7/Xj2 1bnKvIwbtx5Yr1nT+9uXltVcZ13La+HUFIDpoWNZ+sNGNsQdYEPcAZya6Xj31ecZ0qd7jXVYk6Oj I7m5uej1euzt7S0uLyQkhJiYGA4ePMjBgwfR6XSMGTOGJ5988oF1CwoKAFiwYIEy79atB/uqadOm JpdtCrMCfeZ8+ZG0u9/jyrxFy6LIzM7l20+n0sHLg+F/+rDWMkxdv+vjnmTeuMWlqxn4+3qTnpnD 9M/+HwN6B/DG+BEAuLu6kJaRzbZVnytHYEvUtbyK89HePbrSu0dXrl3PZvfBk3y3No5/RMQ8skB7 enqSm5tLRkYG7du3JycnhxUrVtCtWzeGDx9e7TY2NjaUlZVRWlpKaWmp0bIuXbrQpUsXsrOzOX36 NNu3b2fz5s3Vhs7Z2ZmcnBw++eSTWu8QrOgrU8o2hcnn0JnZuaxYtw0HezsmPT9YmV9YXAJAkyZ2 bPgpAcdmOgAKCosBcLC3K9/+3hHuYetXNT54IFqtllUbdnI3v5DI9TtJy8jGxub+Lgx6urwzdh04 yalfUhg2aRazFn5f532r2kZTy5u18HtGvjKHgsIiBvR+AgDHZtX/NqlNxc39pj769euHVqtl9+7d FBYWsnv3bnJycpT7haueKgghcHV1BcqvkJw5cwY7Oztl+cqVK5k/fz5FRUV069YNAJ1OhxBCWe/W rVsIIQgICADg1KlTpKSk8NFHH7Fy5coa662tbFMfldnMnz9//sM6+Ifo7cr/m7YfxNPDjdlTJ9DJ +zFlHefmjvz862V+ik+kWxcf+gT6c+b8ZbbvP8Hzw4MoKCzmXMo14vYmMm7MgIeuX5WrS3N8O7Rj f+IZlq/ZQm5ePi+N6sfksUOVn3p/X2+KivWs37qfuD3HeKJrB957LUT5YanYj1deHFbtdNU2mlpe Ow9XLlxKZ/XGXcTuPIJf5/Z8MOUlWjo71dq/0dHRRjcnjRw58mEvSbWcnJxo27YtZ8+eJS4ujvz8 fIKCghg0aJCyzq5duwCUeS1btuTy5cskJSXh6+vLlStXKC4upn///ri6upKens6ePXs4evQoXl5e PP/88zg6OlJcXExaWhrHjx+nb9++eHl5odfrOXjwIMePH8fHx4dnn30WBweHautt1apVjWWbasuW Lfc/uSLknTANbty4cUb3Qy9durSBW/Tb8s4779y/H7qB2yJVo6yWN6pS7WSgGyHDvas+kulkoBuh imu0kulkoBshGWjzyUA3QlWvB0t1JwPdCFS+cUij0chzaBNV7j8Z6Eagffv2Rteh5RHaNJX7TxMW FiYAZsyY0aCNkiRrkB/BklRFBlpSFRloSVVkoCVVkYGWVEUGWlIVGWhJVWSgJVWRgZZURQZaUhUZ aElVzLo5qVevXixatMjow5e9evUiMTHRag2rq/Dw8AfmhYaGVrteaGio8r+16tRqtTg7O9O7d2/a tav74JWNRV37r77rtlY/mhXoJk2asHXrVvr06UOTJjWPZPSomPICVKwbHR3N2LFjLa7TYDCQmppK fHw8kyZNMru8hvSoAlxb3dbqR7MCrdfrGT9+PJGRkbz22mtGy1JTU5k3bx4XLlygQ4cOzJs3j1at WjF58mTWr1+PVquluLiYF198kaioKBwcHDAYDIwdO5YVK1bQokULs3emsqysLHbv3k1BQQGBgYHK /PDwcHx8fLh58ybh4eFMnjzZ4lGGDAaDMn7b7du3iY+PJycnBxcXFwYMGECLFi2IiIigW7du/Prr rwQFBXH9+nXOnTtHnz596NixI7m5ucTHx3Pz5k1cXFzo378/Op2O6OhoJk6ciFarxWAwsHr1asaO HUtJSckD9bi4uFi0H5VV1x5nZ2ciIyPx9fXlzJkzvPbaa+Tl5REfH09WVhbOzs7069cPNze3avvh Ye2zRj+aFWghBD169GDTpk1kZWUZjRgZFhbGpEmT6Nu3LwkJCSxcuJDly5cTEBBAfHw8gwYNIi4u jtu3bxMXF0dwcDB79+7F39/f7DBX/bUZGhrKoUOH8PPzw9fXl7NnzxotHzp0qMWnHuHh4djY2NC8 eXOaNm3KwIHl493t37+fgIAAvLy8SE1NZf/+/Tz77LPo9XqcnZ0ZOnQosbGx9O3bl9GjRxMbG0vH jh1JSEjAx8eH0aNH88svv3Dw4EFGjRqFm5sbaWlpeHp6cu3aNdzc3NDpdOzatavaeszdl8pCQ0Nr bE9JSQkODg688sorAOzbtw8vLy9GjBhBamoq+/btIyQkpMZ+qO9+tOgG/ylTprBs2TLmzr0/9tuJ Eyc4fPiwMl0x0MjYsWNZtmwZgwYNIjo6milTpvDjjz8SHBxMVFQUb775ptntqC6YOTk5jBgxAjs7 O7p27cqhQ4fMLr+mOs+dO4ezszNt2rRR5mdkZJCWlqZMVwyLJYTA29sbGxsb9Ho9Pj4+2NjYUFJS PoJUVlYWw4YNw9bWli5dunD8+HEAOnXqRHJyMp6enqSkpNCpU6da6zF3X6qqqT1CCPz8/JQjaUZG BkOHDsXW1hYfHx/l+xXr2j5r96NFgfbw8MDd3Z2TJ08q8+zt7dmxY4cyKF+FgIAAcnNz2bZtG4WF hYwfP54NGzawfft2cnNzlaGkrKXyV33V10eaunTpQkJCAk5OTjRrVj5wpY2NDS+//LIyVFZllb+u repXt1V81W9V3t7eHD58GL1eT1paGn369HloPdZQU3sAozprWs+U9lmzHy2+bDd58mQiIiKUN4dP PvkkkZGRFBUVsXHjRt566y1l3ZCQEMLCwggJCUGj0RASEsJnn33GCy+8UFPxZnNxceH8+fOUlpY+ cMoB5e+qCwsLLa4nMDCQw4cPK4PDtGnThlOnTlFaWsq5c+eIjY2tUznu7u6cO3dOaW/FaZyNjQ1t 27bl6NGjtGvXTjlSmVtPXdXUnqo8PDxISkpCr9eTnJzMunXrzGqftfrR4kDrdDqGDRumHPKnT5/O iRMnGDp0KKtXrzb6dTZy5EhsbW0ZPXo0AKNGjcLOzo4RI0ZY1Ibw8HCjB0Dv3r05ffo0kZGR2NjY PPCTHBQUxNq1ay2qF8qv+HTr1k05pQkKCiIjI4OIiAiSkpKo6zf1Pv300yQnJxMREcHly5cJCro/ vl/nzp05c+YMHTt2NGq/OfXUVW3tqSwoKIj09HQiIyM5fvw4/fr1M6t91upH+ZlCSVXkXwolVZGB llRFBlpSFRloSVVkoCVVkYGWVEUGWlIVGWhJVWSgJVWRgZZURQZaUhUZaElVlPuhz527iqO7W0O2 RZIsZnSDv5Od7pE34HraVTzaej3yeiV1kqcckqrIQEuqIgMtqYoMtKQqMtCSqshAS6oiAy2pigy0 pCoy0JKq/CYCHRO3nYKCgjqv79O+JT7tW5J0+oTRtKR+jT7QexMOcfT4SaI3bTZ526i16yktvT+d c8OKDZMapUYd6Cup19ixdy8guJhyiV17E+q8rb29A8eOJVBcaDyQ4JIvPuPp/+xG545tGDLoD+zf F09ZaSk+7VsS2NOX1atW0P2Jx+nRvRMb1q8lfPnXBPh784fArvz0UwwAt2/n8v60t+nRvRNPBnTg zdCXuXEjy5q7Lpmp0Qa6oKCAqH9vAgFCABqIT0jg0pUrddq+uLgIP7/uHD162Gj+tPc/ZMeOJLZt +4Xk5AvM+OA9DIbye7Ru3rwJwpElX37HrZs5zP5wGi2au/K/X/1AVlYmC+bPoaQYPprzPj9G/4u/ f/0vln69jri4WGZ/+AH1NMipZAKLhtOtT+s2xZJ39y5oNJQPiitAQPSmWN56dTKOzRwfWsaQIc+x bdt643KjVvPZp3PJzb0FQHr6Ve7eLV9mMJQxaNAYWriUd0thYQH9+4fQvEX5dEbGNfLzYcf2rQBM nDhMKffwob3k3wWn5pbtt2SZRnmE3rVvH8mXLoOA8n/unTZoIO9uPmv/HYNer39oOT16BHHi5CHs 7w26DhAW9jG5ubeIibk/prWh7P42TZrYo9PdH6nUzs4eXdPyaSEEhjLQNS0fw/jAgeskJt4kMfEm u3aloC8xd48la2l0gc7OucW5X1Nwd3OjjXtr3N1ccXN1xd3VFXc3V9q0dufu3QJ+vZjy0LK0Wi2B gX+guKhImae/N+zv2bOnlCF2i4qMx4m+N056jdMDBgwBYNu29VxITiAoyIMPZoynpaupeytZW6M7 5XBt5cJfXp9stfJGjXqOyIjvlOk3Qt/mm398RXz8Fv46bS7hy//GhAn9TCpz7rzPMBhsWLp0PiUl Rfyhd1/++72F5N0GJ+t855FkJmV86ODg8Q3yyZH6+sRKxSW6Vm6g18Od3PvThQXljyb2YGMDhYWg 1cC9weNp5fZgGVWnhYD8u6AvKX9uaweOjqA1HlddesQa3RHaWlpV+niknZ3xtK5p+aPy9MPKqDqt 0YCjk+XtlKyr0Z1DS5IlZKAlVZGBllRFBlpSFRloSVVkoCVVkYGWVEW5Du3o7kae3vKvCjZHQ9Ur qY8S6HYtH/24dgC0lOPaSdYjTzkkVZGBllRFBlpSFRloSVVkoCVVkYGWVEUGWlIVGWhJVVQbaE3V T7bWc5n1UV9tHnV9vxUmfQQrXKOhZ8+edV7/2LFjhArx8BUlyVrCwsJEWFiYqKvl5Z8JfehjOdS5 zMp27twp/P39hYODg/D19RVxcXHKsnXr1omOHTsKe3t74efnJ+Lj45VlZ8+eFd26dROurq4iJiZG UKn++iizqtqWXbt2TQwYMEA4OjqKvn37isuXLyvLbty4IUaOHCl0Op144oknxJEjR+rU7trq+z0z OdBCPDzU5oZZCCH8/PzE5s2bRVFRkfj++++Fj4+PsszV1VUcOXJElJSUiDVr1ogePXooy4KDg8X8 +fPFnTt3xMcff2z0gtdHmVXVtmzixIlixowZ4s6dO2LOnDli3LhxyrLJkyeLmTNniry8PLF+/Xqj +mtrtwx09cwKtBA1h9qSMFdVXFz8QDBnzpxpdISr4ObmJrKysoQQQqSlpdX4gtdHmULUHjAPDw+R kZEhhBAiMzNTPPbYY8oyd3d3kZmZWeO2NbVbBrp6Zr8pDBWC8Crzwu/Nt0R8fDyBgYE4OTmh0xnf ARgTE0N2djZPPfUU3bt3Z+/evcqy3NxcXFxcAHB1da33MjUaTZ3fmOXk5Cjbt2rViuzsbGXZrVu3 aNmy+rGra2u3VANzj9AVllv5yNymTRuxatUqcefOHZGXl1ftkchgMIjIyEjh6empzHN1dVWOplev XjXarj7KrKq2ZW3btlWOwpmZmaJt27bKMg8PD5GamlrtdrW1u7b6fs8svmxXcaS21tWMLl264Ovr S0lJCYsXL8bNzY2LFy8C0Lt3b6KioigtLaVDhw6Uld0fZTEwMJB//vOf3L17l++++87o6FkfZZpi yJAhLF26lPz8fJYsWcLgwYOVZSNHjmTRokXk5uYSFRWFv79/ndot1cDSI7S1JSYmChcXF+Ht7S22 b98u5s2bJ5o2bSqEECIuLk74+vqKJk2aiM6dO4vY2Fhlu1OnTomuXbuKVq1aiY0bNwqdTicMBkO9 lVkV94dJVR4V0tLSRP/+/YWjo6MYPHiwSEtLU5ZlZ2eL4cOHC3t7e+Hv7y8OHjxYp75AHqGrpYxt N2PGjIb7qZIkK1HtXwql3ycZaElVZKAlVZGBllRFBlpSFRloSVVkoCVVUe6HvnnrdkO2Q5KsQgl0 E12zhmyHJFmFPOWQVEUGWlIVGWhJVWSgJVWRgZZURQZaUhUZaElVGl2gnXR2yqN92zZM+OOL/JyU VKdtS0tLmffRbNxbNre4DRXGjHrGorKkR8ukkZPW6OxMHjlpQqHe5EblFeoxGAykXr3K6lURPDNs ENt2xPMffn61bpd27RpffrGI1OtZJtdZk4sXLlitLKn+mRToCYV61ujsCK3DuuH31jeXVqulvbc3 H86Zi1ar5fNPPyFyzf8BkJFxnSmvv8qhgwfo2SuQf0VF06KFMz2fLP+AqaeHO3mFevbE7+aD9/+b lORkPL28WLzkKwYPGQqUH4XzKrWv6jTAwH5BpKZexUlnx/QZs5g7f4HZ+yM9Giafckwo1D8wHkdV loa5qldefY19e/co0zPen4afnz8pV9LoFfgUH8/7CIDs3LsASjCnT3uPBf/zOdcysvnrtA94d+pf TKp3994EpTwZ5t8Gk47QFSYU6gmv4Uht7TADODu7cOfO/Zun4nfv4sjxkzRzdGTqu+8xsG9Qtdsd OXZKef7SuPG8NeV1q7ZLanzMflNY3ZG6PsIMcPnSJdzc3JXpvLw7dPT2xElnRwevtmRkXK92u317 99A/qDdt3Fxwc3GyerukxseiqxyVQ11fYQZYFfEDAwcPUabd3VtzPesmeYV68gr1yqlGVX9+eRJ/ mfoOF1Oukp6ZY7RMq9Wi15e3Nysrs17aLT16Fl+2qwh1fYQ5PT2NxQs/J2LlD3wwY5Yyf8iwYfzt qy8pKCgg4ocVjB4xrNrtO/v60qmzLyX6Er763yW4urqRkpwMQJs2HmzdEsvdvDz+9uUSbG2rP/t6 7LG2pCQnU1JSYvX9k6zPrHPoqqwd5orrwE2bNaNPn75s3baTDo8/riyfv+B/eGvKG3Ro3xZPT0/+ 9vU31Zbzadgixox8hhYtWvD1N8vQaDT851M9yMy5zdyPF/DO2+VvEsMWf4GjoxNCiAeG+4resInn g0dx5/YdLqWmW3U/JetTRk56+91pDd0WSbJYo/tLoSRZQgZaUhUZaElVZKAlVZGBllRFBlpSFRlo SVWUP6yUFOY3ZDskySqUQLd0adGQ7ZAkq5CnHJKqyEBLqiIDLamKDLSkKjLQkqrIQEuqIgMtqYoM tKQqMtCSqshAS6oiAy2pigy0pCoy0JKqyEBLqiIDLamKDLSkKjLQkqrIQEuqIgMtqYoMtKQqMtCS qshAS6oiAy2pigy0pCr/H+pGyQEKLWVgAAAAAElFTkSuQmCC ------=_Part_4640012_120094896.1399991871152--

4 4

[QE] oVirt 3.5.0 Alpha status
by Sandro Bonazzola 14 May '14

14 May '14

Hi, We're going to start composing oVirt 3.5.0 Alpha on 2014-05-16 08:00 UTC from master branches. The bug tracker [1] shows the following proposed blockers to be reviewed: Bug ID Whiteboard Status Summary 1001100 integration NEW Add log gathering for a new ovirt module (External scheduler) 1073944 integration ASSIGNED Add log gathering for a new ovirt module (External scheduler) 1060198 integration NEW [RFE] add support for Fedora 20 Feature freeze has been postponed to 2014-05-30 and the following features should be testable in 3.5.0 Alpha according to Features Status Table [2] Group oVirt BZ Title gluster 1096713 Monitoring (UI plugin) Dashboard (Integrated with Nagios monitoring) infra 1090530 [RFE] Please add host count and guest count columns to "Clusters" tab in webadmin infra 1054778 [RFE] Allow to perform fence operations from a host in another DC infra 1090803 [RFE] Change the "Slot" field to "Service Profile" when cisco_ucs is selected as the fencing type infra 1090511 [RFE] Improve fencing robustness by retrying failed attempts infra 1090794 [RFE] Search VMs based on MAC address from web-admin portal infra 1090793 consider the event type while printing events to engine.log infra 1090796 [RFE] Re-work engine ovirt-node host-deploy sequence infra 1090798 [RFE] Admin GUI - Add host uptime information to the "General" tab infra 1090808 [RFE] Ability to dismiss alerts and events from web-admin portal infra-api 1090797 [RFE] RESTAPI: Add /tags sub-collection for Template resource infra-dwh 1091686 prevent OutOfMemoryError after starting the dwh service. network 1078836 Add a warning when adding display network network 1079719 Display of NIC Slave/Bond fault on Event Log network 1080987 Support ethtool_opts functionality within oVirt storage 1054241 Store OVF on any domains storage 1083312 Disk alias recycling in web-admin portal ux 1064543 oVirt new look and feel [PatternFly adoption] - phase #1 virt 1058832 Allow to clone a (down) VM without snapshot/template virt 1031040 can't set different keymap for vnc via runonce option virt 1043471 oVirt guest agent for SLES virt 1083049 add progress bar for vm migration virt 1083065 EL 7 guest compatibility virt 1083059 "Instance types (new template handling) - adding flavours" virt Allow guest serial number to be configurable virt 1047624 [RFE] support BIOS boot device menu virt 1083129 allows setting netbios name, locale, language and keyboard settings for windows vm's virt 1038632 spice-html5 button to show debug console/output window virt 1080002 [RFE] Enable user defined Windows Sysprep file done Some more features may be included since they were near to be completed on last sync meeting. The table will be updated on next sync meeting scheduled for 2014-05-14. There are still 383 bugs [3] targeted to 3.5.0. Excluding node and documentation bugs we still have 321 bugs [4] targeted to 3.5.0. Maintainers / Assignee: - Please remember to rebuild your packages before 2014-05-16 08:00 UTC if needed, otherwise nightly snapshot will be taken. - If you find a blocker bug please remember to add it to the tracker [1] - Please start filling release notes, the page has been created here [5] All users: - You're welcome to join us testing this alpha release and getting involved in oVirt Quality Assurance[6]! [1] http://bugzilla.redhat.com/1073943 [2] http://bit.ly/17qBn6F [3] http://red.ht/1pVEk7H [4] http://red.ht/1rLCJwF [5] http://www.ovirt.org/OVirt_3.5_Release_Notes [6] http://www.ovirt.org/OVirt_Quality_Assurance Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

improving VDSM error reporting
by Yoav Kleinberger 14 May '14

14 May '14

Hi all, This idea was born from this bug: https://bugzilla.redhat.com/730619 If, for example, creating a new storage domain fails because there's no space left, the user gets: "Error creating a storage domain" which is not very helpful, since the real problem (no space) is not reported. "Error creating a storage domain" [i] No space left on device Where [i] is some widget the user can open to see details, or other element the UX team find acceptable. Nir Soffer and I believe a good solution is the following: 1. Currently VDSM sends a dictionary {'status': {'code': code, 'message': msg}}. The code is some number that Engine recognizes and has a localized message for. The msg parameter is ignored by Engine, and contains a default, not informative, string like "Error creating a storage domain" 2. We suggest adding a new key to this dictionary, call it "details", which will contain the string representation of the actual exception thrown in Python (in this case, OSError with the string "[Errno 28] No space left on device" 3. The Engine will look for this key, and display the string inside a "details" section which will be added to the current dialog box. The user gets the usual error indication, but has a small "details" icon, which he can click to see more information. The advantages are: 1. Simple to implement 2. Will improve the situation for any error thrown from Python - the user will get a clearer message. 3. New VDSM with old Engine is not a problem, the engine will not look for this key at all 4. New Engine with old VDSM is also easy to handle: the engine will not display "details" if this key is absent. Disadvatage is that the "details" will be non-localized, but this is natural for technical details. Why not use the existing "msg" field? because a new engine with an old VDSM will display uninformative, duplicate messages for all errors (the current msg field is simply a duplicate of the engine error name). What do you think? Yoav K

4 10

[vdsm] pep8 issue
by Amador Pahim 13 May '14

13 May '14

Building vdsm/master in F20, I've got: ./vdsm/virt/migration.py:223:19: E225 missing whitespace around operator In vdsm/virt/migration.py: 223 -1, -1) # int1, int2$ pep8 is not accepting the negative integer. Instead, it is handling the minus sign as an operator. Quick workaround is change -1 to int("-1"). Is this a known issue? I'm using python-pep8-1.5.4-1.fc20.noarch -- Pahim

1 0

UI plugins :: SystemTreeSelectionChange event
by Vojtech Szocs 13 May '14

13 May '14

Hey guys, UI plugin API now supports SystemTreeSelectionChange event, which is fired whenever "System Tree" selection (currently selected tree node) is changed. Example usage: api.register({ SystemTreeSelectionChange: function(selectedNode) { // See SystemTreeItemType Java enum for all supported values var nodeType = selectedNode.type; // Defined only if selected node has an entity associated var associatedEntity = selectedNode.entity; var associatedEntityId = associatedEntity && associatedEntity.id; } }); More details in UI plugin wiki: http://www.ovirt.org/Features/UIPlugins#System_tree_node_selection Regards, Vojtech

1 0

All-in-one engine setup for 3.5
by Piotr Kliczewski 13 May '14

13 May '14

I tried to deploy all in one engine (built from master) and noticed engine setup failed with: 2014-05-13 12:42:40 DEBUG otopi.context context._executeMethod:152 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 142, in _executeMethod method['method']() File "/usr/share/ovirt-**FILTERED**/setup/bin/../plugins/ovirt-**FILTERED**-setup/ovirt-**FILTERED**/all-in-one/vdsm.py", line 190, in _closeup **FILTERED**_api = self._waitEngineUp() File "/usr/share/ovirt-**FILTERED**/setup/bin/../plugins/ovirt-**FILTERED**-setup/ovirt-**FILTERED**/all-in-one/vdsm.py", line 127, in _waitEngineUp except self._ovirtsdk_api.RequestError: AttributeError: 'module' object has no attribute 'RequestError' Can someone help me to understand how to fix this issue? Thanks, Piotr

1 1

Building log collector rpm
by Piotr Kliczewski 13 May '14

13 May '14

I want to build log collector rpm and noticed that is failing due to: + /usr/lib/rpm/redhat/brp-java-repack-jars Processing files: ovirt-log-collector-3.5.0-0.0.master.fc19.noarch error: File not found by glob: /home/pkliczewski/rpmbuild/BUILDROOT/ovirt-log-collector-3.5.0-0.0.master.fc19.x86_64/usr/lib/python2.7/site-packages/sos/plugins/*.py* I pulled the code from master few minutes ago. Can someone help to solve this issue? Thanks, Piotr

2 8

New repos request
by Sandro Bonazzola 13 May '14

13 May '14

Hi, can you please create the following repositories? ovirt-setup: will have ovirt-engine-setup python sources currently shipped within ovirt-engine in packaging/setup. Since it will be able to install dwh / reports / websocket on host where ovirt-engine is not installed I think that calling it ovirt-engine-setup doesn't make much sense. ovirt-lib-python: will have python common libraries currently shipped within ovirt-engine in packaging/pythonlib. python suffix is used following http://fedoraproject.org/wiki/Packaging:NamingGuidelines Comments are welcome. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

[Ovirt-jenkins-question] How to re-trigger the failed gerrit-triggered jobs
by Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) 13 May '14

13 May '14

Hi all, There is a findbugs build failure as below. But I checked the Jenkins console log of that job; it seems the failure is not caused by my code. I have rerun the job and it passed. My question is how can I re-trigger the failed Jenkins job and let it removed the "-1" review score on the gerrit. Thanks & Best Regards Shi, Xiao-Lei (Bruce) Hewlett-Packard Co., Ltd. HP Servers Core Platform Software China Telephone +86 23 65683093 Mobile +86 18696583447 Email xiao-lei.shi(a)hp.com -----Original Message----- From: oVirt Jenkins CI Server [mailto:gerrit2@gerrit.ovirt.org] Sent: Tuesday, May 13, 2014 5:21 AM To: Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) Cc: Gilad Chaplik; automation(a)ovirt.org; Doron Fediuck; Roy Golan; Eli Mesika; Omer Frenkel; Arik Hadas; Martin Sivák; Eli Mesika; Jiří Moskovčák; Kobi Ianko; Vitor de Lima; Leonardo Bianconi; Gustavo Frederico Temple Pedrosa Subject: Change in ovirt-engine[master]: engine: Numa feature entities oVirt Jenkins CI Server has posted comments on this change. Change subject: engine: Numa feature entities ...................................................................... Patch Set 29: Code-Review-1 Verified-1 Build Unstable http://jenkins.ovirt.org/job/ovirt-engine_master_unit-tests_gerrit/7636/ : SUCCESS http://jenkins.ovirt.org/job/ovirt-engine_master_dao_unit_tests_gerrit/2253/ : SUCCESS http://jenkins.ovirt.org/job/ovirt-engine_master_find-bugs_gerrit/6944/ : The patch does not pass the findbugs http://jenkins.ovirt.org/job/ovirt_engine_master_compile_checkstyle_gerrit/… : SUCCESS -- To view, visit http://gerrit.ovirt.org/23702 To unsubscribe, visit http://gerrit.ovirt.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ifefade432e7955503980bdc6fc5d73ea32818a95 Gerrit-PatchSet: 29 Gerrit-Project: ovirt-engine Gerrit-Branch: master Gerrit-Owner: Xiaolei Shi <xiao-lei.shi(a)hp.com> Gerrit-Reviewer: Arik Hadas <ahadas(a)redhat.com> Gerrit-Reviewer: Doron Fediuck <dfediuck(a)redhat.com> Gerrit-Reviewer: Eli Mesika <elimesika(a)gmail.com> Gerrit-Reviewer: Eli Mesika <emesika(a)redhat.com> Gerrit-Reviewer: Gilad Chaplik <gchaplik(a)redhat.com> Gerrit-Reviewer: Gustavo Frederico Temple Pedrosa <gustavo.pedrosa(a)eldorado.org.br> Gerrit-Reviewer: Jiří Moskovčák <jmoskovc(a)redhat.com> Gerrit-Reviewer: Kobi Ianko <kobi(a)redhat.com> Gerrit-Reviewer: Leonardo Bianconi <leonardo.bianconi(a)eldorado.org.br> Gerrit-Reviewer: Martin Sivák <msivak(a)redhat.com> Gerrit-Reviewer: Omer Frenkel <ofrenkel(a)redhat.com> Gerrit-Reviewer: Roy Golan <rgolan(a)redhat.com> Gerrit-Reviewer: Vitor de Lima <vitor.lima(a)eldorado.org.br> Gerrit-Reviewer: Xiaolei Shi <xiao-lei.shi(a)hp.com> Gerrit-Reviewer: automation(a)ovirt.org Gerrit-Reviewer: oVirt Jenkins CI Server Gerrit-HasComments: No

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

oVirt Node ISO rpm-wrapper update
by Fabian Deutsch 12 May '14

12 May '14

--=-XY7myqfQdPvMEZ9t/p3A Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey, the "wrapper rpm" I am going to talk about is an rpm which contains the Node ISO image which can be used easily with oVirt Engine. yum can be used to update this rpm and retrieve the latest oVirt Node iso for easy consumption. For some time we did not deliver Node for Engine in a wrapper rpm because a lot of things have changed (see below for the full story). To get this working again I've been cleaning up the repo and the contained spec. Th repo layout is now: node-3.0 branch: Builds the base image from scratch ovirt-3.4 branch: Builds the iso for Engine using edit-node and the base image Open issues: A repo file needs to be generated on each build which=20 contains all the relevant oVirt repositories. Sandro, do you have an idea how we can retrieve all list of all relevant oVirt repositories using some curl oneliner? The repositories are needed by edit-node to pull in the dependencies of ovirt-node-plugin-vdsm (vdsm, gluster, ...). The changes are _slightly_ tested, and once they are in a better shape we can update Jenkins to use these repos to build the image and rpm for Engine. Technical background story: The problem was that the basic way of how the oVirt Node for Engine ISO was build was dramatically changed. Originally the vdsm packages were part of Node's build process. You build the Node and it was usable with Engine. Now - After we introduced plugins, vdsm was migrated into a plugin (ovirt-node-plugin-vdsm) and the plugin is not part of Node's build process. ISOs we build these days do not contain vdsm specific bits and are called "base images". So if you build Node these days, it is _not_ usable with Engine. Don't Panic. The ovirt-node-plugin-vdsm is added to the "base image" in a second step using edit-node. This process is now used in ovirt-3.4 branch, where also the spec file for the wrapper-rpm resides. - fabian --=-XY7myqfQdPvMEZ9t/p3A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJTcKsRAAoJEC9+uOgSHVGUxbEQAK2F3zufJIRKGmp+VNcqzDkG +C81XqLodPpC80HXRHzbbDb/rGeA3yqcXGa34L17Nz7OhoBIXnDZIY3/Uzjw0PfG BYPkHZYtWZhR/CFQGRDSrANFb2ucxIbvetOXjKK5fgGhuXP20C8TpC6YxdmnTLcG J3/RysEwluoz6j6MfqN8IgqngMeZfit/uFqLk+E2fMaIexYa6VyM8JBnN9nLL6ck 0z+9FKT4da4jFFH5dgTAyi0Y8DL4mxyvORTqzFqFAv0aMyGHXz94KKchmCn6JaBD 3GfpQbxbFJg0jKj9DtzOkL3kQPvPU5vymnJXbrG/mwHPIWTxfGaHGjSg8p1hfRcG jNDVk8Isg1m4BBMy55aP4xB/KuEr4wNl62YrXUMeQHSAPJHaAWmo72IgJFFXVxcQ mTMTKw7E/4MY3wcJRhFcl/kroE3e6foiuRRjoPDuP6VHMv68d3PcfhduzQpq+rvx KuGBmkcMU99IzyUPYovEMZb4goKuHU6GtRVwnI53HVcnQg53FO2Kixmby3gto8MD xDBCtQkertQuXwIkWbuNArfxu+WkqT2dS2vWhsgvmhpNnvP7lUC0zFptcQvcalIu jn3yk7GjWFIJwndLoXI3klwms8pbs0GNRKEQ9OCxHnTCIzmpmTGU9/bIShwVoHAn M4rT42Cpspd3QPwY0/T6 =L21D -----END PGP SIGNATURE----- --=-XY7myqfQdPvMEZ9t/p3A--

1 0

oVirt Node Base Image Beta for 3.0.5
by Fabian Deutsch 12 May '14

12 May '14

--=-uIJ746Bmq+LGquccyMbi Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey, finally there is a (beta of a) new oVirt Node Base Image. Before we let this be the base of the Node for Engine image, we should thoroughly test it. The image is available here: http://fedorapeople.org/~fabiand/node/3.0.5-beta/ovirt-node-base-image-3.0.= 4-20140512.0.iso The image is a snapshot of the node-3.0 branch. Please give it a go and test the rudimentary functionality: - Installation (single, multiple disks) - Network configuration - SSH - ... Greetings fabian --=-uIJ746Bmq+LGquccyMbi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJTcKr+AAoJEC9+uOgSHVGU7B4P/RscJf92o+bWcZfm6MVtt/Fw 94dA69mnnIF+L8vQO+XCBxgew5MVADp+AKTGHAnbs/ydVlobLpxURirKAOw1xoLx sgAYFRIM0LHzkurlqSIOhdiuXPTD/TtzsCr7VrW+K4YxcfcR/VbY0vI20Vd46CNS dAfIZ80+CYgpbpFAelEo+XDWGgMV2qTeeMAYn0x7JbamaGX3Rrz42qZ4rjSwDEFM Zc6Tzw3Di/4wC/DrEr3HEhdsw7hkedexqsVWNK/4k7Jzxz7Omv3bUMYOR/DjAGTB c/AnLUSNuMIpjLhofuqVUOMHKsJD1D0/SgeUuOUcTblh70ksdltpVLO3GOkUL168 vr3361IN4Z1e8IST34DImd7ZpWSZp4NNPzbiNyc3sQ7QEN0fS3vI6I1B3zysQEwy Q9RmT51/cyGMBz9Cm5WvRR+A7N/YZRne4H4OKeyTC+OJoZ3AG8751SODAcNbxF2Y kPyl585ozVrRt2G2Eq6yCEY5D2rXM2qq40/moosck2fLiDiyZF+h5snQGGz5vlHv 7XdfWbmnztfA+/AwG7is/lnXx061UXtXjqv3dxKTleSONNTyU9nuBp2CqnhBs+ft mYnxo+yLqZpwpZYfjZDH9peU+iQ7+7TpHOVdsMYJsi9zDrkv45d9jGO7tqDxFwtX mTBrHVrrH4zWidLBS/qO =9hdL -----END PGP SIGNATURE----- --=-uIJ746Bmq+LGquccyMbi--

1 0

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

ovirt-engine unit tests failing
by Anmol Babu 12 May '14

12 May '14

Hi, ovirt engine master make with UT enabled is failing with the following error : 11:08:31,288 ERROR [ServletUtils] Error sending file "/doesnotexist/iamprettysure". java.io.FileNotFoundException: /doesnotexist/iamprettysure (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(FileInputStream.java:146) at org.ovirt.engine.core.utils.servlet.ServletUtils.writeFileToStream(ServletUtils.java:152) at org.ovirt.engine.core.utils.servlet.ServletUtilsTest.testWriteFileToStream_IOException(ServletUtilsTest.java:99) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) at com.sun.proxy.$Proxy0.invoke(Unknown Source) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) 11:08:31,290 ERROR [ServletUtils] The path is 1300 characters long, which is longer than the maximum allowed 512. 11:08:31,290 ERROR [ServletUtils] The path contains potentially dangerous directory navigation sequences. 11:08:31,290 ERROR [ServletUtils] The path contains potentially dangerous directory navigation sequences. 11:08:31,290 ERROR [ServletUtils] The path contains potentially dangerous directory navigation sequences. 11:08:31,290 ERROR [ServletUtils] The path contains potentially dangerous directory navigation sequences. 11:08:31,290 ERROR [ServletUtils] The path "/../hosts" is not sane, will return null. 11:08:31,299 ERROR [ServletUtils] Can't read file "/etc/doesntexist" for request "null", will send a 404 error response. Tests run: 22, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.194 sec <<< FAILURE! Running org.ovirt.engine.core.utils.servlet.DocsServletTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.001 sec Running org.ovirt.engine.core.utils.servlet.LocaleFilterTest Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.03 sec Running org.ovirt.engine.core.utils.servlet.FileServletTest 11:08:31,502 ERROR [FileServlet] Can't get base name from parameter "file". 11:08:31,505 ERROR [ServletUtils] Can't read file "" for request "null", will send a 404 error response. 11:08:31,512 INFO [FileServlet] Index is "/home/ababu/git-srcs/ovirt-engine/backend/manager/modules/utils/target/test-classes/org/ovirt/engine/core/utils/servlet/index.html". 11:08:31,512 ERROR [FileServlet] There is no index page for directory "/home/ababu/git-srcs/ovirt-engine/backend/manager/modules/utils/target/test-classes/org/ovirt/engine/core/utils/servlet", will send a 404 error response. 11:08:31,514 INFO [FileServlet] Index is "/home/ababu/git-srcs/ovirt-engine/backend/manager/modules/utils/target/test-classes/org/ovirt/engine/core/utils/servlet/filetest/index.html". 11:08:31,517 INFO [FileServlet] Index is "/home/ababu/git-srcs/ovirt-engine/backend/manager/modules/utils/target/test-classes/org/ovirt/engine/core/utils/servlet/filetest/index.html". Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.027 sec Running org.ovirt.engine.core.utils.LocaleUtilsTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.ovirt.engine.core.utils.archivers.tar.TarTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec Running org.ovirt.engine.core.utils.FileUtilTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.124 sec Results : Failed tests: testCanReadFile(org.ovirt.engine.core.utils.servlet.ServletUtilsTest): We should not be able to read this file. Tests run: 275, Failures: 1, Errors: 0, Skipped: 2

1 0

oVirt April 2014 Updates
by Itamar Heim 11 May '14

11 May '14

(a bit late this month) Updates - oVirt 3.4.1 GA - oVirt 3.5 Storage overview http://www.slideshare.net/AllonMureinik/ovirt-2014featurereview35 - Nagios/Icinga monitoring plugin check_rhev3 1.4 released http://lists.ovirt.org/pipermail/users/2014-April/023617.html - oVirt Guest Agent Repo for SLES 11 SP3 is available http://lists.ovirt.org/pipermail/users/2014-April/023542.html Conferences - Help us spread the word about oVirt http://lists.ovirt.org/pipermail/users/2014-April/023929.html - This weekend: FISL 2015 - oVirt Red Hat Summit 2014 Report http://alturl.com/sk5fc - Ravi Nori presented oVirt Overview in Northeast Linux Fest http://northeastlinuxfest.org/?p=222 - OSDC 2013 | Rene Koch: Enterprise Open Source Virtualisierung mit oVirt und RHEV (German) https://www.youtube.com/watch?v=HVG0UrvJhUg - Grazer Linuxtage 2014 sessions and booth by Rene Koch, Peter Stoeckl and Frantisek Kobzik (German) http://glt14-programm.linuxtage.at/events/281.de.html http://glt14-programm.linuxtage.at/events/282.de.html Devel - AngularJS UI plugin sample (Vojtech Szocs) http://lists.ovirt.org/pipermail/users/2014-April/023275.html http://lists.ovirt.org/pipermail/users/2014-April/023673.html - oVirt JavaScript SDK (Design Proposal) http://lists.ovirt.org/pipermail/users/2014-April/023060.html From the Web - Why oVirt 3.4 Rocks! (video) https://www.youtube.com/watch?v=ay4V34NkvS8 - oVirt Is Planning Some Virtualization Improvements http://www.phoronix.com/scan.php?page=news_item&px=MTY1NjE - Personal Projects: oVirt At Home http://gurucollege.net/technology/personal-projects-ovirt-at-home/ - HowTo: Reset/change admin password http://alturl.com/onrpd - HowTo: Change default console to NoVNC http://alturl.com/3ryst - Hosted Engine install (video, russian) http://alturl.com/v2iv2 - Installing oVirt 3.4 http://www.peterfranza.com/2014/04/09/installing-ovirt-3-4/ - Internal/Isolated networks on oVirt http://freedominterface.org/?p=260

1 0

Question about node migrations and hooks
by richard.seguin＠marisec.ca 10 May '14

10 May '14

Good morning, I have two questions. 1. Is there a way to make hooks so that they apply to all instances and templates? rather than setting one at a time? 2. I believe I already have the answer to this, however I just want to be sure that there isn't a better way. I have a ovirt node that basically uses NFS for everything (data and ISOs), and it is slow as heck to get an instance to build. I'm using a 100MB switch, I have a feeling that this needs to be upgraded... Software wise though, is there anything I can do to speed up template deployments to that node? Thanks, Richard Seguin

3 2

supervdsm spams scans for scsi?
by Sven Kieske 09 May '14

09 May '14

Hi, just found this in supervdsm.log: MainProcess|storageRefresh::DEBUG::2014-03-19 17:34:57,752::iscsi::390::Storage.Misc.excCmd::(forceScsiScan) '/bin/dd of=/sys/class/scsi_host/host0/scan' (cwd None) MainProcess|storageRefresh::DEBUG::2014-03-19 17:34:57,764::iscsi::390::Storage.Misc.excCmd::(forceScsiScan) '/bin/dd of=/sys/class/scsi_host/host1/scan' (cwd None) MainProcess|storageRefresh::DEBUG::2014-03-19 17:34:57,766::iscsi::390::Storage.Misc.excCmd::(forceScsiScan) '/bin/dd of=/sys/class/scsi_host/host2/scan' (cwd None) MainProcess|storageRefresh::DEBUG::2014-03-19 17:34:57,768::iscsi::390::Storage.Misc.excCmd::(forceScsiScan) '/bin/dd of=/sys/class/scsi_host/host3/scan' (cwd None) MainProcess|storageRefresh::DEBUG::2014-03-19 17:34:58,771::iscsi::390::Storage.Misc.excCmd::(forceScsiScan) '/bin/dd of=/sys/class/scsi_host/host4/scan' (cwd None) MainProcess|storageRefresh::DEBUG::2014-03-19 17:34:58,774::iscsi::390::Storage.Misc.excCmd::(forceScsiScan) '/bin/dd of=/sys/class/scsi_host/host5/scan' (cwd None) MainProcess|storageRefresh::DEBUG::2014-03-19 17:34:58,776::iscsi::390::Storage.Misc.excCmd::(forceScsiScan) '/bin/dd of=/sys/class/scsi_host/host6/scan' (cwd None) Is there any reason why this is run on hosts which don't got any scsi volumes at all? These messages fill up to 10% of the whole supervdsm.log vdsm version: vdsm-4.13.3-3.el6.x86_64 Shouldn't this just be called if I invoke such a method via webadmin/api ? -- 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

oVirt 3.5.0 release schedule updated
by Sandro Bonazzola 09 May '14

09 May '14

Here is the updated schedule for oVirt 3.5.0. These are tentative planning dates and may change: General availability: 2014-08-04 RC Build: 2014-07-15 oVirt 3.5 Second Test Day: 2014-07-01 Branching - Beta release: 2014-06-16 oVirt 3.5 First Test Day: 2014-06-05 Feature freeze - 2nd Alpha: 2014-05-30 Alpha release: 2014-05-16 Release management page has been updated accordingly: http://www.ovirt.org/OVirt_3.5_release-management oVirt Google Calendar has been updated accordingly: ICAL: https://www.google.com/calendar/ical/ppqtk46u9cglj7l987ruo2l0f8%40group.cal… XML: https://www.google.com/calendar/feeds/ppqtk46u9cglj7l987ruo2l0f8%40group.ca… HTML: https://www.google.com/calendar/embed?src=ppqtk46u9cglj7l987ruo2l0f8%40grou… -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

[ANN] oVirt 3.4.1 Release is now available
by Sandro Bonazzola 08 May '14

08 May '14

The oVirt development team is pleased to announce the general availability of oVirt 3.4.1 as of May 8th 2014. This release solidifies oVirt as a leading KVM management application and open source alternative to VMware vSphere. oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5 (or similar). This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed. The existing repository ovirt-3.4 has been updated for delivering this release without the need of enabling any other repository, however since we introduced package signing you need an additional step in order to get the public keys installed on your system. Please refer to release notes [1] for Installation / Upgrade instructions. For Fedora 19 users, a known issue may cause installation failure due to recent changes in sos package. Please refer to release notes [1] known issues for resolving on your system. A new oVirt Node and oVirt Live ISO will be available [2]. [1] http://www.ovirt.org/OVirt_3.4.1_release_notes [2] http://resources.ovirt.org/plain/pub/ovirt-3.4/iso/ -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

4 7

oVirt 3.4.2 references
by Sandro Bonazzola 08 May '14

08 May '14

Hi, while we're performing last check on 3.4.1 repo before announcing it, here [1] you can find all the references for the pages related to 3.4.2 including: - Bug Tracker [2] - Release notes [3] - Testing results [4] Proposed timeline [5] is: - General availability: 2014-06-10 - RC Build: 2014-05-27 [1] http://www.ovirt.org/OVirt_3.4.z_release-management#oVirt_3.4.2 [2] http://bugzilla.redhat.com/1095370 [3] http://www.ovirt.org/OVirt_3.4.2_Release_Notes [4] http://www.ovirt.org/Testing/oVirt_3.4.2_Testing [5] http://www.ovirt.org/OVirt_3.4.z_release-management#Timeline Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

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

Re: [ovirt-devel] commons-collections v4.0
by Yevgeny Zaspitsky 08 May '14

08 May '14

----_com.android.email_1462209507407830 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 T24gdGhlIG90aGVyIGhhbmQsIGNoYW5naW5nIGEgamFyIGluIHRoZSBydW50aW1lIGVudmlyb25t ZW50IHdpdGhvdXQgY29tcGlsaW5nIGFuZCBydW5uaW5nIHRlc3Qgd2l0aCB0aGUgbmV3IGphciBj b3VsZCBsZWFkIGFuIGFwcGxpY2F0aW9uIHRvIHN0b3AgZnVuY3Rpb25pbmcgaW4gYSBjdXN0b21l ciBlbnZpcm9ubWVudC4KQWxzbyBub3QgZXZlcnkgYnVnIGZvdW5kIGluIGEgZGVwZW5kZW5jeSBq YXIgd291bGQgY2F1c2UgYSBwcm9ibGVtIGluIHRoZSBhcHBsaWNhdGlvbi4gKEFuIGFwcGxpY2F0 aW9uIG1pZ2h0IG5vdCB1c2UgdGhlIHByb2JsZW1hdGljIHBhcnQgb2YgdGhlIGRlcGVuZGVuY3ku KQpJJ2QgYmV0dGVyIHRydXN0IHRoZSB0ZXN0IHN1aXRlIChhdXRvbWF0aWMgYW5kIG1hbnVhbCkg dGhhdCB3ZSBydW4gb24gdGhlIGNvbXBpbGVkIGFwcGxpY2F0aW9uIHdpdGggYWxsIHRoZSBkZXBl bmRlbmNpZXMgdGhhdCB0aGUgZGV2ZWxvcGVycyBjaG9vc2UgYXQgdGhlIGRldmVsb3BtZW50IHRp bWUgYW5kIHRoZW4gZGVsaXZlciB0aGF0ICh3aXRoIGl0cyBkZXBlbmRlbmNpZXMgYXMgYSBzaW5n bGUgcGFja2FnZSkgdG8gdGhlIGN1c3RvbWVycy4KRXZlcnkgYnVnIGluIGEgZGVwZW5kZW5jeSBz aG91bGQgYmUgZXZhbHVhdGVkIHdpdGhpbiB0aGUgZ2l2ZW4gYXBwbGljYXRpb24gc2NvcGUgYW5k IG9ubHkgaWYgcHJvdmVuIGFzIHRoZSBnaXZlbiBhcHBsaWNhdGlvbiBwcm9ibGVtIG9ubHkgdGhl biB0aGUgYXBwbGljYXRpb24gc2hvdWxkIGJlIHJlbGVhc2VkLgoKClNlbnQgZnJvbSBTYW1zdW5n IE1vYmlsZQoKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQpGcm9tOiBBbG9uIEJh ci1MZXYgPGFsb25ibEByZWRoYXQuY29tPiAKRGF0ZTogMDcvMDUvMjAxNCAgMjE6NDEgIChHTVQr MDI6MDApIApUbzogTWlrZSBLb2xlc25payA8bWtvbGVzbmlAcmVkaGF0LmNvbT4gCkNjOiBZZXZn ZW55IFphc3BpdHNreSA8eXphc3BpdHNAcmVkaGF0LmNvbT4sZGV2ZWxAb3ZpcnQub3JnIApTdWJq ZWN0OiBSZTogW292aXJ0LWRldmVsXSBjb21tb25zLWNvbGxlY3Rpb25zIHY0LjAgCiAKCgotLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogIk1pa2UgS29sZXNuaWsiIDxta29sZXNu aUByZWRoYXQuY29tPgo+IFRvOiAiQWxvbiBCYXItTGV2IiA8YWxvbmJsQHJlZGhhdC5jb20+Cj4g Q2M6ICJZZXZnZW55IFphc3BpdHNreSIgPHl6YXNwaXRzQHJlZGhhdC5jb20+LCBkZXZlbEBvdmly dC5vcmcKPiBTZW50OiBXZWRuZXNkYXksIE1heSA3LCAyMDE0IDk6MzQ6MDMgUE0KPiBTdWJqZWN0 OiBSZTogW292aXJ0LWRldmVsXSBjb21tb25zLWNvbGxlY3Rpb25zIHY0LjAKPiAKPiAtLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gPiAKPiA+IAo+ID4gLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLQo+ID4gPiBGcm9tOiAiWWV2Z2VueSBaYXNwaXRza3kiIDx5emFzcGl0c0ByZWRoYXQu Y29tPgo+ID4gPiBUbzogIkFsb24gQmFyLUxldiIgPGFsb25ibEByZWRoYXQuY29tPgo+ID4gPiBD YzogZGV2ZWxAb3ZpcnQub3JnCj4gPiA+IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDIyLCAyMDE0IDEx OjM5OjExIEFNCj4gPiA+IFN1YmplY3Q6IFJlOiBbb3ZpcnQtZGV2ZWxdIGNvbW1vbnMtY29sbGVj dGlvbnMgdjQuMAo+ID4gPiAKPiA+ID4gVGhhdCBtZWFucyB0aGF0IHdlIG1hbmFnZSAyIHNlcGFy YXRlIGVudmlyb25tZW50czoKPiA+ID4gMS4gRGV2ZWxvcG1lbnQgLSByZWxpZXMgb24gcG9tIGZp bGVzLiBFLmcuIHVuaXQgdGVzdHMgcnVuIHdpdGgKPiA+ID4gY29tbW9ucy1jb2xsZWN0aW9ucyB2 My4xIChhbmQgd2hlbiBJIGFkZCB2NC4wKSBhbmQgc3VjY2VlZC4KPiA+IAo+ID4gZGV2ZW52IHdp bGwgdXNlIHJ1bnRpbWUgb3B0aW9uLgo+ID4geW91IGFyZSByaWdodCBhYm91dCB0aGUgdW5pdCB0 ZXN0cywgdGhlc2UgcmVsYXlzIG9uIHRoZSBwb21zLgo+IAo+IEkgdXNlIGRldmVudiBhbmQgaXQg YWx3YXlzIHVzZXMgdGhlIGRldiBvcHRpb24gbm90IHRoZSBydW50aW1lLgo+IFNvIGJhc2ljYWxs eSBkZXZlbG9wZXJzIGFyZSB1c2luZyB0aGUgcG9tIHNwZWNpZmllZCB2ZXJzaW9ucyBhbmQgbm90 IHdoYXQKPiB1c2VkIGluIHJ1bnRpbWUuCj4gCj4gRXZlbiBtb3JlIHNvLCBpbiBydW50aW1lIGl0 IGhpZ2hseSBkZXBlbmRzIG9uIHdoYXQgT1MgeW91J3JlIHVzaW5nLCBzbwo+IHNvbWVvbmUKPiBk ZXZlbG9waW5nIG9uIEYxOSBtaWdodCBub3QgYmUgdXNpbmcgc2FtZSB2ZXJzaW9ucyBhcyBhIGRl dmVsb3BlciBvbiBGMjAgYW5kCj4gYm90aCBhcmUgcHJvYmFibHkgdmVyeSBkaWZmZXJlbnQgdmVy c2lvbnMgdGhhbiBvbiBSSEVML0NlbnRPUy4KPiBJIHdvbid0IGV2ZW4gbWVudGlvbiBvdGhlciBP U2BzLgo+IAo+ID4gCj4gPiA+IDIuIFJ1bi10aW1lIC0gcmVsaWVzIG9uIEpCb3NzIG93biBkZXBl bmRlbmNpZXMgdGhhdCBicmluZwo+ID4gPiBjb21tb25zLWNvbGxlY3Rpb24KPiA+ID4gdjMuMi4x LXJlZGhhdC0yLgo+ID4gCj4gPiBpbiByaGVsIGNhc2UsIHllcy4KPiA+IAo+ID4gPiBUaGlzIGtp bmQgb2YgZGlzY3JlcGFuY2llcyBtaWdodCBiZSBmb3VuZCBpbiBvdGhlciBsaWJyYXJpZXMgYXMg d2UgZG8gbm90Cj4gPiA+IHN5bmNocm9uaXplIG91ciBwb20gZmlsZXMgd2l0aCB0aGUgSkJvc3Mg Y3VycmVudCB2ZXJzaW9uIGRlcGVuZGVuY2llcy4KPiA+ID4gSU1ITyB0aGF0IGNvdWxkIGxlYWQg dG8gc29tZSB2ZXJ5IGRpZmZpY3VsdCBidWdzIHRoYXQgd2Ugd29uJ3QgYmUgYWJsZSB0bwo+ID4g PiBzaW11bGF0ZSBpbiBvdXIgdW5pdCB0ZXN0cy4KPiA+IAo+ID4gY29ycmVjdCwgYnV0IHRoZSBq YXZhIHdheSB0byBwdWxsIGRlcGVuZGVuY2llcyBhdCB3aWxsIHdpdGhvdXQgYmVpbmcgYWJsZQo+ ID4gdG8KPiA+IGZpeCB6LXN0cmVhbSB1c2luZyBjZW50cmFsIHBhY2thZ2UgbWFuYWdlbWVudCB0 b29scyBpcyBtb3JlIHNldmVyZSB0aGFuCj4gPiB1bml0Cj4gPiB0ZXN0cyBub3Qgd29ya2luZy9u b3Qgd29ya2luZy4KPiA+IAo+ID4gZm9yIGV4YW1wbGUsIHlvdXIgYXBwbGljYXRpb24gdXNlcyB4 LmphciBhbmQgYWN0dWFsbHkgZGVsaXZlcnMgeC5qYXIuLi4gc28KPiA+IGZyb20gcmVsZWFzZSB0 byBldGVybml0eSBpdCBpcyB5b3VyIHJlc3BvbnNpYmlsaXR5IHRvIHRyYWNrIHguamFyIGZvcgo+ ID4gc2V2ZXJlCj4gPiBzdGFiaWxpdHkgYnVncyBhbmQgc2VjdXJpdHkgYnVncywgYW5kIHJlbGVh c2UgeW91ciBlbnRpcmUgYXBwbGljYXRpb24gZWFjaAo+ID4gdGltZSBmb3VuZCwgbm93IG11bHRp cGxlIGl0IHdpdGggdGhlICMgb2YgY29tcG9uZW50cyBhcHBsaWNhdGlvbiBpcyB1c2luZwo+ID4g YW5kIHNlZSBob3cgbXVjaCBlZmZvcnQgeW91IGhhdmUganVzdCB0byBtYWludGFpbiBzdGFiaWxp dHkgYW5kIHNlY3VyaXR5IGlmCj4gPiB5b3UgZW1iZWQgM3JkIHBhcnR5IGNvbXBvbmVudHMgd2l0 aG91dCB5b3VyIGFwcGxpY2F0aW9uLgo+IAo+IFllcywgaWYgeW91IHVzZSBwYWNrYWdlIFggdGhl biB5b3UncmUgdXNpbmcgdGhhdCBzcGVjaWZpYyB2ZXJzaW9uIHdpdGggaXQncwo+IGJlaGF2aW91 ciBhbmQgQVBJLCB0aGlzIGlzIHdoeSBkZXBlbmRlbmNpZXMgYXJlbid0IHVwZGF0ZWQgbGlnaHQg aGVhZGVkbHkgYnV0Cj4gd2l0aCB0ZXN0aW5nIHRvIHNlZSB0aGF0IG5vdGhpbmcgYnJva2UgKHNp bmNlIHN0dWZmIGRvZXMgYnJlYWssIGV2ZW4gaW4gbWlub3IKPiB2ZXJzaW9uLCBhcyB3ZSBsZWF2 ZSBpbiBhIG5vdCBzbyBwZXJmZWN0IHdvcmxkKS4KPiAKPiA+IAo+ID4gPiBXaHkgZG8gd2UgYXZv aWQgInRvIG1haW50YWluIG91ciBvd24gcGFja2FnaW5nIj8gSU1ITyBPdmlydCBvd24KPiA+ID4g ZGVwZW5kZW5jaWVzCj4gPiA+IGNvdWxkIGJlIHBhY2tlZCBpbiB0aGUgd2FyLCBjYW4ndCB0aGV5 Pwo+ID4gCj4gPiB5ZXMgdGhleSBjb3VsZCwgYnV0IHRoaXMgaXMgbm90IHN1aXRhYmxlIGZvciBl bnRlcnByaXNlIGdyYWRlCj4gPiBpbXBsZW1lbnRhdGlvbnMsIG1haW5seSBwZXIgd2hhdCBJIGRl c2NyaWJlZCBhYm92ZS4KPiAKPiBTb3JyeSBidXQgQUZBSUsgZW50ZXJwcmlzZSBncmFkZSBzb2Z0 d2FyZSByZWxlYXNlIGZpeGVzIGZvciB0aGVpciBzb2Z0d2FyZQo+IG9uIGEgdGltZWx5IGJhc2lz IGFuZCBoYXZlIHByb2Nlc3NlcyBpbiBwbGFjZSB0byBtYW5hZ2UgdXBncmFkZXMgb2YKPiBmdW5j dGlvbmFsaXR5Lgo+IAo+IFdoYXQgY3VycmVudGx5IGlzIGRvbmUgaXMgcmVseWluZyBvbiBjb3Vy dGVzeSBvZiBvdGhlciBwZW9wbGUgdG8gcmVsZWFzZSBhCj4gImZpeCIgdGhhdCBhbHJlYWR5IGV4 aXN0cyBhIGxvbmcgdGltZS4KPiBBbmQgb2YgY291cnNlLCBhcyBJIG1lbnRpb25lZCwgdGhlIGFw cGxpY2F0aW9uIG5lZWRzIHRvIGJlIHRlc3RlZCB3aXRoIHRoZQo+IHVwZGF0ZWQgbGlicmFyeS4K PiBJTU8gbmVnbGVjdGluZyB0aGlzIGFuZCBsZWF2aW5nIHRoaXMgb3V0IG9mIGJhbmQgZm9yICJl bnRlcnByaXNlIGdyYWRlIgo+IHNvZnR3YXJlIGlzIG11Y2ggd29yc2UgdGhhbiBhY3R1YWxseSB0 ZXN0aW5nIHRvIHNlZSB0aGF0IGl0IGlzIHdvcmtpbmcgYW5kCj4ganVzdCBsZWF2aW5nIGl0IGFs bCB0byBjaGFuY2UuCgrigI5XZWxsLCB0YWtlIHRoZSByZWNlbnQgZXhhbXBsZSBvZiBvcGVuc3Ns IGlzc3VlIHRoYXQgd2FzIGZvdW5kLgpOb3csIGltYWdpbmUgdGhhdCBhbGwgcHJvZHVjdHMgdGhh dCB1c2Ugb3BlbnNzbCBzaG91bGQgaGF2ZSBiZWVuIHJlLXJlbGVhc2VkLgpJIHRoaW5rIHRoaXMg aXMgZW5vdWdoIHRvIHVuZGVyc3RhbmQgaG93IHdyb25nIHRoaXMgaXMuCgo+IAo+ID4gCj4gPiBS ZWdhcmRzLAo+ID4gQWxvbgo+ID4gCj4gPiA+IEJlc3QgcmVnYXJkcywKPiA+ID4gX19fX19fX19f X19fX19fX19fX18KPiA+ID4gWWV2Z2VueSBaYXNwaXRza3kKPiA+ID4gU2VuaW9yIFNvZnR3YXJl IEVuZ2luZWVyCj4gPiA+IFJlZCBIYXQgSXNyYWVsCj4gPiA+IAo+ID4gPiAKPiA+ID4gLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo+ID4gPiBGcm9tOiAiQWxvbiBCYXItTGV2IiA8YWxvbmJs QHJlZGhhdC5jb20+Cj4gPiA+IFRvOiAiWWV2Z2VueSBaYXNwaXRza3kiIDx5emFzcGl0c0ByZWRo YXQuY29tPgo+ID4gPiBDYzogZGV2ZWxAb3ZpcnQub3JnCj4gPiA+IFNlbnQ6IFN1bmRheSwgQXBy aWwgMTMsIDIwMTQgNzoyMjoxOCBQTQo+ID4gPiBTdWJqZWN0OiBSZTogW292aXJ0LWRldmVsXSBj b21tb25zLWNvbGxlY3Rpb25zIHY0LjAKPiA+ID4gCj4gPiA+IAo+ID4gPiAKPiA+ID4gLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo+ID4gPiA+IEZyb206ICJZZXZnZW55IFphc3BpdHNreSIg PHl6YXNwaXRzQHJlZGhhdC5jb20+Cj4gPiA+ID4gVG86IGRldmVsQG92aXJ0Lm9yZwo+ID4gPiA+ IFNlbnQ6IFN1bmRheSwgQXByaWwgMTMsIDIwMTQgNzoxMzoxMCBQTQo+ID4gPiA+IFN1YmplY3Q6 IFtvdmlydC1kZXZlbF0gY29tbW9ucy1jb2xsZWN0aW9ucyB2NC4wCj4gPiA+ID4gCj4gPiA+ID4g SGkgQWxsLAo+ID4gPiA+IAo+ID4gPiA+IEknZCBsaWtlIHRvIGFkZCB0aGUgbmV3IHZlcnNpb24g KDQuMCkgb2YgQXBhY2hlIGNvbW1vbnMtY29sbGVjdGlvbnMKPiA+ID4gPiBsaWJyYXJ5Cj4gPiA+ ID4gdG8gdGhlIGRlcGVuZGVuY2llcyBvZiB0aGUgcHJvamVjdCAod2UgdXNlIDMuMSBjdXJyZW50 bHkpLgo+ID4gPiA+IFRoZSBuZXcgdmVyc2lvbiB1c2VzIHRoZSBnZW5lcmljcyBmZWF0dXJlcyBv ZiBKYXZhIDUgc28gdGhhdCBtYWtlIHRoZQo+ID4gPiA+IGNvZGUKPiA+ID4gPiBtb3JlIHR5cGUg c2FmZS4gWW91IGNhbiBmaW5kIHRoZSBmdWxsIGxpc3Qgb2YgY2hhbmdlcyBvbgo+ID4gPiA+IGh0 dHBzOi8vY29tbW9ucy5hcGFjaGUub3JnL3Byb3Blci9jb21tb25zLWNvbGxlY3Rpb25zL3JlbGVh c2VfNF8wLmh0bWwuCj4gPiA+ID4gVGhlIG5ldyBBUEkgaXMgYmFzZWQgb24gdGhlIG9yaWdpbmFs IGJ1dCBpdCBpc24ndCBmdWxseSBjb21wYXRpYmxlIHdpdGgKPiA+ID4gPiBpdC4KPiA+ID4gPiBT byBpbiBvcmRlciB0byBtYWtlIHRoZSBtaWdyYXRpb24gdG8gdGhlIG5ldyBBUEkgZWFzaWVyLCB0 aGUgcGFja2FnZQo+ID4gPiA+IGhhcwo+ID4gPiA+IGJlZW4gY2hhbmdlZCB0byBvcmcuYXBhY2hl LmNvbW1vbnMuY29sbGVjdGlvbnM0LiBUaGF0IGFsbG93cyBoYXZpbmcKPiA+ID4gPiBib3RoCj4g PiA+ID4gdmVyc2lvbiBvZiB0aGUgbGlicmFyeSBpbiB0aGUgY2xhc3NwYXRoIGF0IHRoZSBzdGFy dGluZyBwb2ludCBhbmQgbW92ZQo+ID4gPiA+IChyZWZhY3RvcikgdG93YXJkcyB0aGUgbmV3IHZl cnNpb24gZ3JhZHVhbGx5Lgo+ID4gPiA+IAo+ID4gPiA+IEkgaGF2ZSBjb3VwbGUgb2YgcXVlc3Rp b25zIHJlZ2FyZGluZyB0aGUgbmV3IGRlcGVuZGVuY3k6Cj4gPiA+ID4gMS4gSXMgdGhlcmUgYW55 dGhpbmcgdGhhdCBjb3VsZCBwcmV2ZW50IGFkZGluZyB0aGUgbmV3IGRlcGVuZGVuY3k/Cj4gPiA+ IAo+ID4gPiBXZSB0cnkgdG8gYXZvaWQgaW50cm9kdWNpbmcgb3VyIG93biBkZXBlbmRlbmNpZXMs IGluIHRoaXMgY2FzZSB3ZSB1c2UKPiA+ID4gd2hhdGV2ZXIgamJvc3MgcHJvdmlkZXMgd2hpY2gg aXMgdmVyeSBjb21mb3J0YWJsZSBhcyB3ZSBkbyBub3QgbmVlZCB0bwo+ID4gPiBtYWludGFpbiBv dXIgb3duIHBhY2thZ2luZy4KPiA+ID4gCj4gPiA+IEN1cnJlbnRseSB0aGUgamJlYXAgZG9lcyBu b3QgcHJvdmlkZSA0LjAsIGl0IGRvZXMgc3VwcG9ydCAzLjIuMS1yZWRoYXQtMiwKPiA+ID4gc28K PiA+ID4gYmV0dGVyIHRvIGF2b2lkIHRoaXMgdW50aWwgd2Ugc3dpdGNoIHRvIG1vcmUgcmVjZW50 IHZlcnNpb24gb2YgamJvc3MuCj4gPiA+IAo+ID4gPiBBbHRlcm5hdGl2ZWx5IHdlIGNvdWxkIGVu am95IHN0YW5kYWxvbmUgcnBtIHdpdGhpbiByaGVsL2NlbnRvcyBpZgo+ID4gPiBhdmFpbGFibGUs Cj4gPiA+IGhvd2V2ZXIgbm9uIGV4aXN0Lgo+ID4gPiAKPiA+ID4gPiAyLiBJIGRpZCB0aGUgY2hh bmdlIChodHRwOi8vZ2Vycml0Lm92aXJ0Lm9yZy8yNjc0NSkuCj4gPiA+ID7CoMKgwqAgVGhlIHVu aXQgdGVzdHMgdGhhdCB1c2UgdGhlIG5ldyBkZXBlbmRlbmN5IHBhc3MgbG9jYWxseSBhbmQgaW4K PiA+ID4gPsKgwqDCoCBKZW5raW5zCj4gPiA+ID7CoMKgwqAgZW52aXJvbm1lbnRzLgo+ID4gPiA+ wqDCoMKgIEhvd2V2ZXIgd2hlbiBJIHRyeSB0byBydW4gYSBjb2RlIHRoYXQgaXMgZGVwZW5kZW50 IG9uIHRoZSBuZXdseQo+ID4gPiA+wqDCoMKgIGFkZGVkCj4gPiA+ID7CoMKgwqAgbGlicmFyeSBO b0NsYXNzRGVmRm91bmRFcnJvciBiZWluZyB0aHJvd24uCj4gPiA+ID7CoMKgwqAgQWxzbyBJIGNh bid0IGZpbmQgY29tbW9ucy1jb2xsZWN0aW9uczQgamFyIHVuZGVyIHRoZSBpbnN0YWxsYXRpb24K PiA+ID4gPsKgwqDCoCBkaXJlY3RvcnkuIEkgdXNlICJtYWtlIGNsZWFuIGluc3RhbGwtZGV2IiBj b21tYW5kIGZvciBidWlsZGluZy4KPiA+ID4gPiAKPiA+ID4gPiBQbGVhc2UgYWR2aXNlLgo+ID4g Cj4gCg== ----_com.android.email_1462209507407830 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5PbiB0aGUgb3RoZXIgaGFu ZCwgY2hhbmdpbmcgYSBqYXIgaW4gdGhlIHJ1bnRpbWUgZW52aXJvbm1lbnQgd2l0aG91dCBjb21w aWxpbmcgYW5kIHJ1bm5pbmcgdGVzdCB3aXRoIHRoZSBuZXcgamFyIGNvdWxkIGxlYWQgYW4gYXBw bGljYXRpb24gdG8gc3RvcCBmdW5jdGlvbmluZyBpbiBhIGN1c3RvbWVyIGVudmlyb25tZW50Ljwv ZGl2PjxkaXY+QWxzbyBub3QgZXZlcnkgYnVnIGZvdW5kIGluIGEgZGVwZW5kZW5jeSBqYXIgd291 bGQgY2F1c2UgYSBwcm9ibGVtIGluIHRoZSBhcHBsaWNhdGlvbi4gKEFuIGFwcGxpY2F0aW9uIG1p Z2h0IG5vdCB1c2UgdGhlIHByb2JsZW1hdGljIHBhcnQgb2YgdGhlIGRlcGVuZGVuY3kuKTwvZGl2 PjxkaXY+SSdkIGJldHRlciB0cnVzdCB0aGUgdGVzdCBzdWl0ZSAoYXV0b21hdGljIGFuZCBtYW51 YWwpIHRoYXQgd2UgcnVuIG9uIHRoZSBjb21waWxlZCBhcHBsaWNhdGlvbiB3aXRoIGFsbCB0aGUg ZGVwZW5kZW5jaWVzIHRoYXQgdGhlIGRldmVsb3BlcnMgY2hvb3NlIGF0IHRoZSBkZXZlbG9wbWVu dCB0aW1lIGFuZCB0aGVuIGRlbGl2ZXIgdGhhdCAod2l0aCBpdHMgZGVwZW5kZW5jaWVzIGFzIGEg c2luZ2xlIHBhY2thZ2UpIHRvIHRoZSBjdXN0b21lcnMuPC9kaXY+PGRpdj5FdmVyeSBidWcgaW4g YSBkZXBlbmRlbmN5IHNob3VsZCBiZSBldmFsdWF0ZWQgd2l0aGluIHRoZSBnaXZlbiBhcHBsaWNh dGlvbiBzY29wZSBhbmQgb25seSBpZiBwcm92ZW4gYXMgdGhlIGdpdmVuIGFwcGxpY2F0aW9uIHBy b2JsZW0gb25seSB0aGVuIHRoZSBhcHBsaWNhdGlvbiBzaG91bGQgYmUgcmVsZWFzZWQuPC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6 NzUlO2NvbG9yOiM1NzU3NTciPlNlbnQgZnJvbSBTYW1zdW5nIE1vYmlsZTwvZGl2PjwvZGl2Pjxi cj48YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08YnI+RnJvbTogQWxv biBCYXItTGV2ICZsdDthbG9uYmxAcmVkaGF0LmNvbSZndDsgPGJyPkRhdGU6IDA3LzA1LzIwMTQg IDIxOjQxICAoR01UKzAyOjAwKSA8YnI+VG86IE1pa2UgS29sZXNuaWsgJmx0O21rb2xlc25pQHJl ZGhhdC5jb20mZ3Q7IDxicj5DYzogWWV2Z2VueSBaYXNwaXRza3kgJmx0O3l6YXNwaXRzQHJlZGhh dC5jb20mZ3Q7LGRldmVsQG92aXJ0Lm9yZyA8YnI+U3ViamVjdDogUmU6IFtvdmlydC1kZXZlbF0g Y29tbW9ucy1jb2xsZWN0aW9ucyB2NC4wIDxicj4gPGJyPjxicj48YnI+PGJyPi0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS08YnI+Jmd0OyBGcm9tOiAiTWlrZSBLb2xlc25payIgJmx0O21rb2xl c25pQHJlZGhhdC5jb20mZ3Q7PGJyPiZndDsgVG86ICJBbG9uIEJhci1MZXYiICZsdDthbG9uYmxA cmVkaGF0LmNvbSZndDs8YnI+Jmd0OyBDYzogIllldmdlbnkgWmFzcGl0c2t5IiAmbHQ7eXphc3Bp dHNAcmVkaGF0LmNvbSZndDssIGRldmVsQG92aXJ0Lm9yZzxicj4mZ3Q7IFNlbnQ6IFdlZG5lc2Rh eSwgTWF5IDcsIDIwMTQgOTozNDowMyBQTTxicj4mZ3Q7IFN1YmplY3Q6IFJlOiBbb3ZpcnQtZGV2 ZWxdIGNvbW1vbnMtY29sbGVjdGlvbnMgdjQuMDxicj4mZ3Q7IDxicj4mZ3Q7IC0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS08YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0 OyAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPGJyPiZndDsgJmd0OyAmZ3Q7IEZyb206ICJZ ZXZnZW55IFphc3BpdHNreSIgJmx0O3l6YXNwaXRzQHJlZGhhdC5jb20mZ3Q7PGJyPiZndDsgJmd0 OyAmZ3Q7IFRvOiAiQWxvbiBCYXItTGV2IiAmbHQ7YWxvbmJsQHJlZGhhdC5jb20mZ3Q7PGJyPiZn dDsgJmd0OyAmZ3Q7IENjOiBkZXZlbEBvdmlydC5vcmc8YnI+Jmd0OyAmZ3Q7ICZndDsgU2VudDog VHVlc2RheSwgQXByaWwgMjIsIDIwMTQgMTE6Mzk6MTEgQU08YnI+Jmd0OyAmZ3Q7ICZndDsgU3Vi amVjdDogUmU6IFtvdmlydC1kZXZlbF0gY29tbW9ucy1jb2xsZWN0aW9ucyB2NC4wPGJyPiZndDsg Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyBUaGF0IG1lYW5zIHRoYXQgd2UgbWFuYWdlIDIg c2VwYXJhdGUgZW52aXJvbm1lbnRzOjxicj4mZ3Q7ICZndDsgJmd0OyAxLiBEZXZlbG9wbWVudCAt IHJlbGllcyBvbiBwb20gZmlsZXMuIEUuZy4gdW5pdCB0ZXN0cyBydW4gd2l0aDxicj4mZ3Q7ICZn dDsgJmd0OyBjb21tb25zLWNvbGxlY3Rpb25zIHYzLjEgKGFuZCB3aGVuIEkgYWRkIHY0LjApIGFu ZCBzdWNjZWVkLjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBkZXZlbnYgd2lsbCB1c2UgcnVu dGltZSBvcHRpb24uPGJyPiZndDsgJmd0OyB5b3UgYXJlIHJpZ2h0IGFib3V0IHRoZSB1bml0IHRl c3RzLCB0aGVzZSByZWxheXMgb24gdGhlIHBvbXMuPGJyPiZndDsgPGJyPiZndDsgSSB1c2UgZGV2 ZW52IGFuZCBpdCBhbHdheXMgdXNlcyB0aGUgZGV2IG9wdGlvbiBub3QgdGhlIHJ1bnRpbWUuPGJy PiZndDsgU28gYmFzaWNhbGx5IGRldmVsb3BlcnMgYXJlIHVzaW5nIHRoZSBwb20gc3BlY2lmaWVk IHZlcnNpb25zIGFuZCBub3Qgd2hhdDxicj4mZ3Q7IHVzZWQgaW4gcnVudGltZS48YnI+Jmd0OyA8 YnI+Jmd0OyBFdmVuIG1vcmUgc28sIGluIHJ1bnRpbWUgaXQgaGlnaGx5IGRlcGVuZHMgb24gd2hh dCBPUyB5b3UncmUgdXNpbmcsIHNvPGJyPiZndDsgc29tZW9uZTxicj4mZ3Q7IGRldmVsb3Bpbmcg b24gRjE5IG1pZ2h0IG5vdCBiZSB1c2luZyBzYW1lIHZlcnNpb25zIGFzIGEgZGV2ZWxvcGVyIG9u IEYyMCBhbmQ8YnI+Jmd0OyBib3RoIGFyZSBwcm9iYWJseSB2ZXJ5IGRpZmZlcmVudCB2ZXJzaW9u cyB0aGFuIG9uIFJIRUwvQ2VudE9TLjxicj4mZ3Q7IEkgd29uJ3QgZXZlbiBtZW50aW9uIG90aGVy IE9TYHMuPGJyPiZndDsgPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgMi4gUnVuLXRp bWUgLSByZWxpZXMgb24gSkJvc3Mgb3duIGRlcGVuZGVuY2llcyB0aGF0IGJyaW5nPGJyPiZndDsg Jmd0OyAmZ3Q7IGNvbW1vbnMtY29sbGVjdGlvbjxicj4mZ3Q7ICZndDsgJmd0OyB2My4yLjEtcmVk aGF0LTIuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IGluIHJoZWwgY2FzZSwgeWVzLjxicj4m Z3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IFRoaXMga2luZCBvZiBkaXNjcmVwYW5jaWVzIG1p Z2h0IGJlIGZvdW5kIGluIG90aGVyIGxpYnJhcmllcyBhcyB3ZSBkbyBub3Q8YnI+Jmd0OyAmZ3Q7 ICZndDsgc3luY2hyb25pemUgb3VyIHBvbSBmaWxlcyB3aXRoIHRoZSBKQm9zcyBjdXJyZW50IHZl cnNpb24gZGVwZW5kZW5jaWVzLjxicj4mZ3Q7ICZndDsgJmd0OyBJTUhPIHRoYXQgY291bGQgbGVh ZCB0byBzb21lIHZlcnkgZGlmZmljdWx0IGJ1Z3MgdGhhdCB3ZSB3b24ndCBiZSBhYmxlIHRvPGJy PiZndDsgJmd0OyAmZ3Q7IHNpbXVsYXRlIGluIG91ciB1bml0IHRlc3RzLjxicj4mZ3Q7ICZndDsg PGJyPiZndDsgJmd0OyBjb3JyZWN0LCBidXQgdGhlIGphdmEgd2F5IHRvIHB1bGwgZGVwZW5kZW5j aWVzIGF0IHdpbGwgd2l0aG91dCBiZWluZyBhYmxlPGJyPiZndDsgJmd0OyB0bzxicj4mZ3Q7ICZn dDsgZml4IHotc3RyZWFtIHVzaW5nIGNlbnRyYWwgcGFja2FnZSBtYW5hZ2VtZW50IHRvb2xzIGlz IG1vcmUgc2V2ZXJlIHRoYW48YnI+Jmd0OyAmZ3Q7IHVuaXQ8YnI+Jmd0OyAmZ3Q7IHRlc3RzIG5v dCB3b3JraW5nL25vdCB3b3JraW5nLjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBmb3IgZXhh bXBsZSwgeW91ciBhcHBsaWNhdGlvbiB1c2VzIHguamFyIGFuZCBhY3R1YWxseSBkZWxpdmVycyB4 Lmphci4uLiBzbzxicj4mZ3Q7ICZndDsgZnJvbSByZWxlYXNlIHRvIGV0ZXJuaXR5IGl0IGlzIHlv dXIgcmVzcG9uc2liaWxpdHkgdG8gdHJhY2sgeC5qYXIgZm9yPGJyPiZndDsgJmd0OyBzZXZlcmU8 YnI+Jmd0OyAmZ3Q7IHN0YWJpbGl0eSBidWdzIGFuZCBzZWN1cml0eSBidWdzLCBhbmQgcmVsZWFz ZSB5b3VyIGVudGlyZSBhcHBsaWNhdGlvbiBlYWNoPGJyPiZndDsgJmd0OyB0aW1lIGZvdW5kLCBu b3cgbXVsdGlwbGUgaXQgd2l0aCB0aGUgIyBvZiBjb21wb25lbnRzIGFwcGxpY2F0aW9uIGlzIHVz aW5nPGJyPiZndDsgJmd0OyBhbmQgc2VlIGhvdyBtdWNoIGVmZm9ydCB5b3UgaGF2ZSBqdXN0IHRv IG1haW50YWluIHN0YWJpbGl0eSBhbmQgc2VjdXJpdHkgaWY8YnI+Jmd0OyAmZ3Q7IHlvdSBlbWJl ZCAzcmQgcGFydHkgY29tcG9uZW50cyB3aXRob3V0IHlvdXIgYXBwbGljYXRpb24uPGJyPiZndDsg PGJyPiZndDsgWWVzLCBpZiB5b3UgdXNlIHBhY2thZ2UgWCB0aGVuIHlvdSdyZSB1c2luZyB0aGF0 IHNwZWNpZmljIHZlcnNpb24gd2l0aCBpdCdzPGJyPiZndDsgYmVoYXZpb3VyIGFuZCBBUEksIHRo aXMgaXMgd2h5IGRlcGVuZGVuY2llcyBhcmVuJ3QgdXBkYXRlZCBsaWdodCBoZWFkZWRseSBidXQ8 YnI+Jmd0OyB3aXRoIHRlc3RpbmcgdG8gc2VlIHRoYXQgbm90aGluZyBicm9rZSAoc2luY2Ugc3R1 ZmYgZG9lcyBicmVhaywgZXZlbiBpbiBtaW5vcjxicj4mZ3Q7IHZlcnNpb24sIGFzIHdlIGxlYXZl IGluIGEgbm90IHNvIHBlcmZlY3Qgd29ybGQpLjxicj4mZ3Q7IDxicj4mZ3Q7ICZndDsgPGJyPiZn dDsgJmd0OyAmZ3Q7IFdoeSBkbyB3ZSBhdm9pZCAidG8gbWFpbnRhaW4gb3VyIG93biBwYWNrYWdp bmciPyBJTUhPIE92aXJ0IG93bjxicj4mZ3Q7ICZndDsgJmd0OyBkZXBlbmRlbmNpZXM8YnI+Jmd0 OyAmZ3Q7ICZndDsgY291bGQgYmUgcGFja2VkIGluIHRoZSB3YXIsIGNhbid0IHRoZXk/PGJyPiZn dDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IHllcyB0aGV5IGNvdWxkLCBidXQgdGhpcyBpcyBub3Qgc3Vp dGFibGUgZm9yIGVudGVycHJpc2UgZ3JhZGU8YnI+Jmd0OyAmZ3Q7IGltcGxlbWVudGF0aW9ucywg bWFpbmx5IHBlciB3aGF0IEkgZGVzY3JpYmVkIGFib3ZlLjxicj4mZ3Q7IDxicj4mZ3Q7IFNvcnJ5 IGJ1dCBBRkFJSyBlbnRlcnByaXNlIGdyYWRlIHNvZnR3YXJlIHJlbGVhc2UgZml4ZXMgZm9yIHRo ZWlyIHNvZnR3YXJlPGJyPiZndDsgb24gYSB0aW1lbHkgYmFzaXMgYW5kIGhhdmUgcHJvY2Vzc2Vz IGluIHBsYWNlIHRvIG1hbmFnZSB1cGdyYWRlcyBvZjxicj4mZ3Q7IGZ1bmN0aW9uYWxpdHkuPGJy PiZndDsgPGJyPiZndDsgV2hhdCBjdXJyZW50bHkgaXMgZG9uZSBpcyByZWx5aW5nIG9uIGNvdXJ0 ZXN5IG9mIG90aGVyIHBlb3BsZSB0byByZWxlYXNlIGE8YnI+Jmd0OyAiZml4IiB0aGF0IGFscmVh ZHkgZXhpc3RzIGEgbG9uZyB0aW1lLjxicj4mZ3Q7IEFuZCBvZiBjb3Vyc2UsIGFzIEkgbWVudGlv bmVkLCB0aGUgYXBwbGljYXRpb24gbmVlZHMgdG8gYmUgdGVzdGVkIHdpdGggdGhlPGJyPiZndDsg dXBkYXRlZCBsaWJyYXJ5Ljxicj4mZ3Q7IElNTyBuZWdsZWN0aW5nIHRoaXMgYW5kIGxlYXZpbmcg dGhpcyBvdXQgb2YgYmFuZCBmb3IgImVudGVycHJpc2UgZ3JhZGUiPGJyPiZndDsgc29mdHdhcmUg aXMgbXVjaCB3b3JzZSB0aGFuIGFjdHVhbGx5IHRlc3RpbmcgdG8gc2VlIHRoYXQgaXQgaXMgd29y a2luZyBhbmQ8YnI+Jmd0OyBqdXN0IGxlYXZpbmcgaXQgYWxsIHRvIGNoYW5jZS48YnI+PGJyPuKA jldlbGwsIHRha2UgdGhlIHJlY2VudCBleGFtcGxlIG9mIG9wZW5zc2wgaXNzdWUgdGhhdCB3YXMg Zm91bmQuPGJyPk5vdywgaW1hZ2luZSB0aGF0IGFsbCBwcm9kdWN0cyB0aGF0IHVzZSBvcGVuc3Ns IHNob3VsZCBoYXZlIGJlZW4gcmUtcmVsZWFzZWQuPGJyPkkgdGhpbmsgdGhpcyBpcyBlbm91Z2gg dG8gdW5kZXJzdGFuZCBob3cgd3JvbmcgdGhpcyBpcy48YnI+PGJyPiZndDsgPGJyPiZndDsgJmd0 OyA8YnI+Jmd0OyAmZ3Q7IFJlZ2FyZHMsPGJyPiZndDsgJmd0OyBBbG9uPGJyPiZndDsgJmd0OyA8 YnI+Jmd0OyAmZ3Q7ICZndDsgQmVzdCByZWdhcmRzLDxicj4mZ3Q7ICZndDsgJmd0OyBfX19fX19f X19fX19fX19fX19fXzxicj4mZ3Q7ICZndDsgJmd0OyBZZXZnZW55IFphc3BpdHNreTxicj4mZ3Q7 ICZndDsgJmd0OyBTZW5pb3IgU29mdHdhcmUgRW5naW5lZXI8YnI+Jmd0OyAmZ3Q7ICZndDsgUmVk IEhhdCBJc3JhZWw8YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7 ICZndDsgJmd0OyAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPGJyPiZndDsgJmd0OyAmZ3Q7 IEZyb206ICJBbG9uIEJhci1MZXYiICZsdDthbG9uYmxAcmVkaGF0LmNvbSZndDs8YnI+Jmd0OyAm Z3Q7ICZndDsgVG86ICJZZXZnZW55IFphc3BpdHNreSIgJmx0O3l6YXNwaXRzQHJlZGhhdC5jb20m Z3Q7PGJyPiZndDsgJmd0OyAmZ3Q7IENjOiBkZXZlbEBvdmlydC5vcmc8YnI+Jmd0OyAmZ3Q7ICZn dDsgU2VudDogU3VuZGF5LCBBcHJpbCAxMywgMjAxNCA3OjIyOjE4IFBNPGJyPiZndDsgJmd0OyAm Z3Q7IFN1YmplY3Q6IFJlOiBbb3ZpcnQtZGV2ZWxdIGNvbW1vbnMtY29sbGVjdGlvbnMgdjQuMDxi cj4mZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IDxi cj4mZ3Q7ICZndDsgJmd0OyAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPGJyPiZndDsgJmd0 OyAmZ3Q7ICZndDsgRnJvbTogIllldmdlbnkgWmFzcGl0c2t5IiAmbHQ7eXphc3BpdHNAcmVkaGF0 LmNvbSZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUbzogZGV2ZWxAb3ZpcnQub3JnPGJyPiZn dDsgJmd0OyAmZ3Q7ICZndDsgU2VudDogU3VuZGF5LCBBcHJpbCAxMywgMjAxNCA3OjEzOjEwIFBN PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogW292aXJ0LWRldmVsXSBjb21tb25zLWNv bGxlY3Rpb25zIHY0LjA8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyBIaSBBbGwsPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7ICZn dDsgSSdkIGxpa2UgdG8gYWRkIHRoZSBuZXcgdmVyc2lvbiAoNC4wKSBvZiBBcGFjaGUgY29tbW9u cy1jb2xsZWN0aW9uczxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGxpYnJhcnk8YnI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyB0byB0aGUgZGVwZW5kZW5jaWVzIG9mIHRoZSBwcm9qZWN0ICh3ZSB1c2UgMy4x IGN1cnJlbnRseSkuPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIG5ldyB2ZXJzaW9uIHVzZXMg dGhlIGdlbmVyaWNzIGZlYXR1cmVzIG9mIEphdmEgNSBzbyB0aGF0IG1ha2UgdGhlPGJyPiZndDsg Jmd0OyAmZ3Q7ICZndDsgY29kZTxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1vcmUgdHlwZSBzYWZl LiBZb3UgY2FuIGZpbmQgdGhlIGZ1bGwgbGlzdCBvZiBjaGFuZ2VzIG9uPGJyPiZndDsgJmd0OyAm Z3Q7ICZndDsgaHR0cHM6Ly9jb21tb25zLmFwYWNoZS5vcmcvcHJvcGVyL2NvbW1vbnMtY29sbGVj dGlvbnMvcmVsZWFzZV80XzAuaHRtbC48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgbmV3IEFQ SSBpcyBiYXNlZCBvbiB0aGUgb3JpZ2luYWwgYnV0IGl0IGlzbid0IGZ1bGx5IGNvbXBhdGlibGUg d2l0aDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGl0Ljxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNv IGluIG9yZGVyIHRvIG1ha2UgdGhlIG1pZ3JhdGlvbiB0byB0aGUgbmV3IEFQSSBlYXNpZXIsIHRo ZSBwYWNrYWdlPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgaGFzPGJyPiZndDsgJmd0OyAmZ3Q7ICZn dDsgYmVlbiBjaGFuZ2VkIHRvIG9yZy5hcGFjaGUuY29tbW9ucy5jb2xsZWN0aW9uczQuIFRoYXQg YWxsb3dzIGhhdmluZzxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGJvdGg8YnI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyB2ZXJzaW9uIG9mIHRoZSBsaWJyYXJ5IGluIHRoZSBjbGFzc3BhdGggYXQgdGhlIHN0 YXJ0aW5nIHBvaW50IGFuZCBtb3ZlPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgKHJlZmFjdG9yKSB0 b3dhcmRzIHRoZSBuZXcgdmVyc2lvbiBncmFkdWFsbHkuPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsg PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgSSBoYXZlIGNvdXBsZSBvZiBxdWVzdGlvbnMgcmVnYXJk aW5nIHRoZSBuZXcgZGVwZW5kZW5jeTo8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAxLiBJcyB0aGVy ZSBhbnl0aGluZyB0aGF0IGNvdWxkIHByZXZlbnQgYWRkaW5nIHRoZSBuZXcgZGVwZW5kZW5jeT88 YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IFdlIHRyeSB0byBhdm9pZCBpbnRy b2R1Y2luZyBvdXIgb3duIGRlcGVuZGVuY2llcywgaW4gdGhpcyBjYXNlIHdlIHVzZTxicj4mZ3Q7 ICZndDsgJmd0OyB3aGF0ZXZlciBqYm9zcyBwcm92aWRlcyB3aGljaCBpcyB2ZXJ5IGNvbWZvcnRh YmxlIGFzIHdlIGRvIG5vdCBuZWVkIHRvPGJyPiZndDsgJmd0OyAmZ3Q7IG1haW50YWluIG91ciBv d24gcGFja2FnaW5nLjxicj4mZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgQ3VycmVu dGx5IHRoZSBqYmVhcCBkb2VzIG5vdCBwcm92aWRlIDQuMCwgaXQgZG9lcyBzdXBwb3J0IDMuMi4x LXJlZGhhdC0yLDxicj4mZ3Q7ICZndDsgJmd0OyBzbzxicj4mZ3Q7ICZndDsgJmd0OyBiZXR0ZXIg dG8gYXZvaWQgdGhpcyB1bnRpbCB3ZSBzd2l0Y2ggdG8gbW9yZSByZWNlbnQgdmVyc2lvbiBvZiBq Ym9zcy48YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IEFsdGVybmF0aXZlbHkg d2UgY291bGQgZW5qb3kgc3RhbmRhbG9uZSBycG0gd2l0aGluIHJoZWwvY2VudG9zIGlmPGJyPiZn dDsgJmd0OyAmZ3Q7IGF2YWlsYWJsZSw8YnI+Jmd0OyAmZ3Q7ICZndDsgaG93ZXZlciBub24gZXhp c3QuPGJyPiZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDIuIEkgZGlkIHRo ZSBjaGFuZ2UgKGh0dHA6Ly9nZXJyaXQub3ZpcnQub3JnLzI2NzQ1KS48YnI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgdW5pdCB0ZXN0cyB0aGF0IHVzZSB0aGUgbmV3 IGRlcGVuZGVuY3kgcGFzcyBsb2NhbGx5IGFuZCBpbjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEplbmtpbnM8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyBlbnZpcm9ubWVudHMuPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsm bmJzcDsgSG93ZXZlciB3aGVuIEkgdHJ5IHRvIHJ1biBhIGNvZGUgdGhhdCBpcyBkZXBlbmRlbnQg b24gdGhlIG5ld2x5PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgYWRk ZWQ8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBsaWJyYXJ5IE5vQ2xh c3NEZWZGb3VuZEVycm9yIGJlaW5nIHRocm93bi48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyBBbHNvIEkgY2FuJ3QgZmluZCBjb21tb25zLWNvbGxlY3Rpb25zNCBqYXIg dW5kZXIgdGhlIGluc3RhbGxhdGlvbjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGRpcmVjdG9yeS4gSSB1c2UgIm1ha2UgY2xlYW4gaW5zdGFsbC1kZXYiIGNvbW1hbmQg Zm9yIGJ1aWxkaW5nLjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7IFBsZWFzZSBhZHZpc2UuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyA8YnI+PC9ib2R5Pg== ----_com.android.email_1462209507407830--

3 3

[VDSM] [PATCH] Add the missing locked() interface
by Nir Soffer 08 May '14

08 May '14

threading.Lock has a little known locked() method, documented in https://docs.python.org/2.6/library/thread.html#thread.lock.locked This method is not very useful, but since pthreading.Lock must be drop-in replacment for threading.Lock, we must implement it. This patch adds the missing method, implementing it in the same way Python implemnts it. Since RLock does not have this method, RLock does not extend Lock now. Signed-off-by: Nir Soffer <nsoffer(a)redhat.com> --- pthreading.py | 18 ++++++++++++++---- tests.py | 7 +++++++ 2 files changed, 21 insertions(+), 4 deletions(-) diff --git a/pthreading.py b/pthreading.py index 2e9e2d6..f1ea056 100644 --- a/pthreading.py +++ b/pthreading.py @@ -51,9 +51,9 @@ import os import pthread -class Lock(pthread.Mutex): +class _Lock(pthread.Mutex): """ - Lock class mimics Python native threading.Lock() API on top of + _Lock class mimics Python native threading.Lock() API on top of the POSIX thread mutex synchronization primitive. """ def __enter__(self): @@ -78,9 +78,19 @@ class Lock(pthread.Mutex): self.unlock() -class RLock(Lock): +class Lock(_Lock): + def locked(self): + # Yes, this is horrible hack, and the same one used by Python + # threadmodule.c. But this is part of Python lock interface. + if self.acquire(blocking=False): + self.release() + return False + return True + + +class RLock(_Lock): def __init__(self): - pthread.Mutex.__init__(self, recursive=True) + _Lock.__init__(self, recursive=True) class Condition(object): diff --git a/tests.py b/tests.py index d651288..f4c9746 100644 --- a/tests.py +++ b/tests.py @@ -60,6 +60,13 @@ class LockTests(TestCaseBase): self.assertTrue(lock.acquire()) self.assertTrue(lock.acquire(False)) + def testLocked(self): + lock = pthreading.Lock() + self.assertFalse(lock.locked()) + with lock: + self.assertTrue(lock.locked()) + self.assertFalse(lock.locked()) + class Flag(object): def __init__(self): -- 1.8.3.1

4 3

just merged the look-and-feel patch -- rebase!
by Greg Sheremeta 07 May '14

07 May '14

Hi, We just merged the look-and-feel patch [1]. The patch is gigantic and touches most parts of the UI, so please do a rebase immediately if you're doing any kind of UI work. If you see any UI look/feel bugs (like things out of place, bad alignment, etc.), open a BZ and assign to me. Thanks! Greg [1] http://gerrit.ovirt.org/#/c/24594/ Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gshereme(a)redhat.com

1 1

oVirt vdsm-jsonrpc-java release
by Piotr Kliczewski 07 May '14

07 May '14

I would like to get a key to sign vdsm-jsonrpc-java artifacts before releasing them to maven central. Thanks, Piotr

2 1

Re: [ovirt-devel] Login is failing at master due to cookie hell
by Alon Bar-Lev 07 May '14

07 May '14

Hi, Thanks Omer for the hint! Following merge of several patches HttpOnly cookie patch[1], and the new theme[2] (I guess), the login stopped working. The frontend is doing basic authentication against the restapi and attempt to move the cookie(?)? But it sending the cookie without http only marker. I do not fully understand the logic, but it may parse the cookie manually in order to do so? Our cookies must have HttpOnly markers so this probably need to be solved at the component which sends the cookie without the HttpOnly. For now, people that experiencing this, please revert[1] until we can sort it out. Thanks, Alon [1] http://gerrit.ovirt.org/#/c/25915/ [2] http://gerrit.ovirt.org/#/c/24594/

3 5

Re: [ovirt-devel] Problem In Ovirt-Node
by Dan Kenigsberg 07 May '14

07 May '14

On Wed, May 07, 2014 at 11:44:02AM +0800, yao xu wrote: > Ah.. > > I replace a new netcard .But the old netcard's mac address is remembered by > ovirt-node .(I can find the old netcard configure file in > /var/lib/statelss/writable/etc/sysconfig/network-scripts/ ) > > Thus when I reboot the machine , the new netcard can't be up. If I remove > the MAC address in configure file , everything will be OK. > > Do you think it is a problem ? Have you ever fix this in new version . > > Thanks for your reply. That's a known issue, to which we do not have a clean-cut solution. However, since ovirt-3.4 [1], you can configure Vdsm to avoid writing HWADDR in its ifcfg files, by setting hwaddr_in_ifcfg = never in /etc/vdsm/vdsm.conf. This can be safely done only if NetworkManager is turned off, or with new versions of NetworkManager (/me thinks 0.9.9.1) that supports "interface-name: unmanaged-spec". [1] http://gerrit.ovirt.org/#/c/22288/6/lib/vdsm/config.py.in

1 0

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

possible 3.4.1 blocker
by Sven Kieske 06 May '14

06 May '14

Hi, please review this bug report: I can't boot this vm via cloud init, this worked before, it causes an unhandled exception in jboss: https://bugzilla.redhat.com/show_bug.cgi?id=1093755 I'm aware I may have an error in my json syntax as this got changed from 3.3.x to 3.4.x . I tried to keep up with the changes and hope I got everything right. So please correct my json, or if it is correct please help me debug while this raises an exception. I believe I'm one of not too many people (maybe the only one?) who tests cloud-init via REST/json so maybe I hit a bug. Thanks for your help in advance. PS: Here again the json for lazy people who don't want to click links ;) {"vm":{"initialization":{"cloud_init":{"host":{"address":"test"},"network_configuration":{"nics":{"nics":[{"name":"eth0","boot_protocol":"STATIC","network":{"ip":{"address":"10.211.0.236","netmask":"255.255.255.248","gateway":"10.211.0.233"}},"on_boot":true}]},"dns":{"servers":{"hosts":[{"address":"46.30.62.99"},{"address":"46.30.62.98"},{"address":"46.30.62.97"}]}}},"users":{"users":[{"name":"root","password":"#9Dh2--3xz-h95Zy"}]},"files":{"files":[{"name":"\/foo\/test","content":"test","type":"PLAINTEXT"}]}}}}} -- 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

4 11

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

Problem In Ovirt-Node
by yao xu 06 May '14

06 May '14

Hi Everyone! I am using ovirt-node 1.9.3 , vdsm 4.10. And I configure them well . But after I replace a net interface , that host will never connect to the storage server any more .

2 2

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

inconsistency in json api vs xml/other apis
by Sven Kieske 05 May '14

05 May '14

Hi, there's an inconsistent use of plural vs singular form regarding the "vm" collection in the apis. in json you got a collection named "vm" which contains a list of vms. in xml and via gui you got a collection "vms" which contains a list of vms. I just stumbled upon it, as I used json api already in 3.3.3. and didn't had time to test 3.4 until now. the upgrade itself went very well, but know I have to deal with this api change and the other entity renamings done in json api. what would make this less painful would be an consistent way of getting the ovirt-version via api, so I could easily split my codepath by first querying the api version. unfortunately also this one got changed in json so I'll need to call for every version that might be there. I understand that part of this problem comes from using json when it was not "official supported", but at least this inconsistence use in different apis makes not really much sense to me. should I file a BZ for this? -- 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

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