February 2014 - Devel - oVirt List Archives

[Engine-devel] [oVirt/RHEV 3.4 Localization Question #16] Strings with resource ID "ActionGroup___"
by Yuko Katabami 13 Feb '14

13 Feb '14

This is a multi-part message in MIME format. --------------020603010501060100010609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello all, I am a Brisbane-based translator working on oVirt 3.4 localization project along with 5 other translators. Our localization cycle is just kicked off and I would like to post our questions here, just like I did for 3.3. It would be appreciated if you could help us. Here is our first question. *File:***LocalizedEnums* **Resource ID:***starting with "ActionGroup___"* **Strings:***including Assign vNIC Profile to Template Assign vNIC Profile to VM Assign vNIC Profile to VM Access Image Storage Domains *Question:* In this file, there are number of strings with the resource ID starting with "ActionGroup___". Could you please let me know the usage? Are these actions used to replace variable in strings such as "Cannot ${action} ${type}"? Or is it more like action buttons? Translation may vary depending on the usage/context and it would be helpful if you could give us some extra information. Kind regards, Yuko --------------020603010501060100010609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> Hello all, I am a Brisbane-based translator working on oVirt 3.4 localization project along with 5 other translators. Our localization cycle is just kicked off and I would like to post our questions here, just like I did for 3.3. It would be appreciated if you could help us. Here is our first question. File: LocalizedEnums Resource ID: starting with  "ActionGroup___" Strings: including Assign vNIC Profile to Template Assign vNIC Profile to VM Assign vNIC Profile to VM Access Image Storage Domains <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> Question: In this file, there are number of strings with the resource ID starting with  "ActionGroup___". Could you please let me know the usage? Are these actions used to replace variable in strings such as "Cannot ${action} ${type}"? Or is it more like action buttons? Translation may vary depending on the usage/context and it would be helpful if you could give us some extra information. Kind regards, Yuko </body> </html> --------------020603010501060100010609--

1 0

[Engine-devel] Spice proxy test day support
by Doron Fediuck 12 Feb '14

12 Feb '14

Hi all, I was testing this feature today and would like to summarize my findings; 1. Feature page http://www.ovirt.org/Features/Spice_Proxy Quite informative. Nevertheless things we should improve: - Please add a contact person in case of question / issues (feature owner?). - Detail design? Nothing mentioned with regards to the implementation. This could be in a separate page, but in such a case I'd add a link to that page. - Missing specific examples. ie- supported protocols: engine-config -s SpiceProxyDefault=http://my-ip:8080 * Did you know that http is a default if no scheme stated? All the above should make this cool feature more easy to use by non-developers. 2. Test cases - System level (using engine-config) - Cluster level - VM-Pool level For each of the above I configured a proxy, and on the proxy machine used: "nc -l 8080" to capture the traffic. In all cases things worked quite nicely. I saw incoming connection request which is what I expected for. 3. All-in-all: We have the functionality working which is the important part. Going forward we should try to improve some of the things I mentioned above. Nice work, Doron P.S. During my tests I managed to open 2 non-related bugs on engine-config and network QoS mapper (Class cast issue).

2 1

[Engine-devel] [ovirt-testday] Fake PPC Support - Feedback
by Vinzenz Feenstra 12 Feb '14

12 Feb '14

This is a multi-part message in MIME format. --------------070509070905070907070200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, On the test day I was testing the Fake PPC support. I managed to register the Fake PPC host into the engine. However when I tried to run the VM it failed with libvirt responding: * libvirtError: internal error: process exited while connecting to monitor: "kvm" accelerator does not exist.** **No accelerator found!** **KVM not supported for this target** *** Which does not make much sense though. Since it should not try to use 'kvm'. And I am not really sure why it does. Please let me know if there's anything else I would need to provide you so you can figure out what is going on. Right now the server is still in the same state. But I eventually will have to use it for something else. Here's the part of the log which prints the generated DomainXML: Thread-77::DEBUG::2014-01-23 15:43:46,834::vm::3130::vm.Vm::(_run) vmId=`a5409fe7-8054-46ce-91c2-2d565e7edc5b`::<?xml version="1.0" encoding="utf-8"?> <domain type="kvm" xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0"> <name>asdfasd</name> <uuid>a5409fe7-8054-46ce-91c2-2d565e7edc5b</uuid> <memory>524288</memory> <currentMemory>524288</currentMemory> <vcpu current="1">1</vcpu> <memtune> <min_guarantee>524288</min_guarantee> </memtune> <devices> <channel type="unix"> <target name="com.redhat.rhevm.vdsm" type="virtio"/> <source mode="bind" path="/var/lib/libvirt/qemu/channels/a5409fe7-8054-46ce-91c2-2d565e7edc5b.com.redhat.rhevm.vdsm"/> </channel> <channel type="unix"> <target name="org.qemu.guest_agent.0" type="virtio"/> <source mode="bind" path="/var/lib/libvirt/qemu/channels/a5409fe7-8054-46ce-91c2-2d565e7edc5b.org.qemu.guest_agent.0"/> </channel> <input bus="usb" type="tablet"/> <graphics autoport="yes" keymap="en-us" listen="0" passwd="*****" passwdValidTo="1970-01-01T00:00:01" port="-1" type="vnc"/> <emulator>/usr/bin/qemu-system-ppc64</emulator> <memballoon model="virtio"/> <controller index="0" type="scsi"> <address type="spapr-vio"/> </controller> <controller index="1" model="virtio-scsi" type="scsi"/> <video> <model heads="1" type="vga" vram="32768"/> </video> <interface type="bridge"> <mac address="00:1a:4a:65:ca:b2"/> <model type="virtio"/> <source bridge="ovirtmgmt"/> <filterref filter="vdsm-no-mac-spoofing"/> <link state="up"/> </interface> <disk device="cdrom" snapshot="no" type="file"> <address bus="0" controller="0" target="0" type="drive" unit="0"/> <source file="" startupPolicy="optional"/> <target bus="scsi" dev="sda"/> <readonly/> <serial/> </disk> <disk device="disk" snapshot="no" type="file"> <source file="/rhev/data-center/mnt/str-02.rhev.lab.eng.brq.redhat.com:_mnt_export_nfs_150_nfs04/efd2a9ce-6417-44e9-ac59-bb577f22bbc3/images/4f6be340-f7b1-4b78-9aa3-7390ffd6bec8/e4f6d99b-c94c-4ae9-8bd6-5212a1d4e9df"/> <target bus="virtio" dev="vda"/> <serial>4f6be340-f7b1-4b78-9aa3-7390ffd6bec8</serial> <boot order="1"/> <driver cache="none" error_policy="stop" io="threads" name="qemu" type="raw"/> </disk> </devices> <os> <type arch="ppc64" machine="pseries">hvm</type> </os> <clock adjustment="0" offset="variable"> <timer name="rtc" tickpolicy="catchup"/> </clock> <cpu> <topology cores="1" sockets="1" threads="1"/> </cpu> <qemu:commandline> <qemu:arg value="-usbdevice"/> <qemu:arg value="keyboard"/> </qemu:commandline> </domain> Thread-77::DEBUG::2014-01-23 15:43:47,566::libvirtconnection::124::root::(wrapper) Unknown libvirterror: ecode: 1 edom: 10 level: 2 message: internal error: process exited while connecting to monitor: "kvm" accelerator does not exist. No accelerator found! KVM not supported for this target Thread-77::DEBUG::2014-01-23 15:43:47,567::vm::2247::vm.Vm::(_startUnderlyingVm) vmId=`a5409fe7-8054-46ce-91c2-2d565e7edc5b`::_ongoingCreations released Thread-77::ERROR::2014-01-23 15:43:47,567::vm::2273::vm.Vm::(_startUnderlyingVm) vmId=`a5409fe7-8054-46ce-91c2-2d565e7edc5b`::The vm start process failed Traceback (most recent call last): File "/usr/share/vdsm/vm.py", line 2233, in _startUnderlyingVm self._run() File "/usr/share/vdsm/vm.py", line 3164, in _run self._connection.createXML(domxml, flags), File "/usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py", line 92, in wrapper ret = f(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2920, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirtError: internal error: process exited while connecting to monitor: "kvm" accelerator does not exist. No accelerator found! KVM not supported for this target Extraction of the capabilities related to this: <guest> <os_type>hvm</os_type> <arch name='ppc'> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-ppc</emulator> <machine>g3beige</machine> <machine>prep</machine> <machine>mpc8544ds</machine> <machine>mac99</machine> <machine>ppce500</machine> <machine>virtex-ml507</machine> <machine>bamboo</machine> <machine>taihu</machine> <machine>ref405ep</machine> <machine>none</machine> <domain type='qemu'> </domain> </arch> <features> <cpuselection/> <deviceboot/> </features> </guest> <guest> <os_type>hvm</os_type> <arch name='ppc64'> <wordsize>64</wordsize> <emulator>/usr/bin/qemu-system-ppc64</emulator> <machine>mac99</machine> <machine>prep</machine> <machine>mpc8544ds</machine> <machine>g3beige</machine> <machine>ppce500</machine> <machine>virtex-ml507</machine> <machine>pseries</machine> <machine>bamboo</machine> <machine>taihu</machine> <machine>ref405ep</machine> <machine>none</machine> <domain type='qemu'> </domain> </arch> <features> <cpuselection/> <deviceboot/> </features> </guest> -- Regards, Vinzenz Feenstra | Senior Software Engineer RedHat Engineering Virtualization R & D Phone: +420 532 294 625 IRC: vfeenstr or evilissimo Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com --------------070509070905070907070200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hi, On the test day I was testing the Fake PPC support. I managed to register the Fake PPC host into the engine. However when I tried to run the VM it failed with libvirt responding: libvirtError: internal error: process exited while connecting to monitor: "kvm" accelerator does not exist. No accelerator found! KVM not supported for this target Which does not make much sense though. Since it should not try to use 'kvm'. And I am not really sure why it does. Please let me know if there's anything else I would need to provide you so you can figure out what is going on. Right now the server is still in the same state. But I eventually will have to use it for something else. Here's the part of the log which prints the generated DomainXML: Thread-77::DEBUG::2014-01-23 15:43:46,834::vm::3130::vm.Vm::(_run) vmId=`a5409fe7-8054-46ce-91c2-2d565e7edc5b`::<?xml version="1.0" encoding="utf-8"?> <domain type="kvm" xmlns:qemu=<a class="moz-txt-link-rfc2396E" href="http://libvirt.org/schemas/domain/qemu/1.0">"http://libvirt.org/schemas/domain/qemu/1.0"</a>>         <name>asdfasd</name>         <uuid>a5409fe7-8054-46ce-91c2-2d565e7edc5b</uuid>         <memory>524288</memory>         <currentMemory>524288</currentMemory>         <vcpu current="1">1</vcpu>         <memtune>                 <min_guarantee>524288</min_guarantee>         </memtune>         <devices>                 <channel type="unix">                         <target name="com.redhat.rhevm.vdsm" type="virtio"/>                         <source mode="bind" path="/var/lib/libvirt/qemu/channels/a5409fe7-8054-46ce-91c2-2d565e7edc5b.com.redhat.rhevm.vdsm"/>                 </channel>                 <channel type="unix">                         <target name="org.qemu.guest_agent.0" type="virtio"/>                         <source mode="bind" path="/var/lib/libvirt/qemu/channels/a5409fe7-8054-46ce-91c2-2d565e7edc5b.org.qemu.guest_agent.0"/>                 </channel>                 <input bus="usb" type="tablet"/>                 <graphics autoport="yes" keymap="en-us" listen="0" passwd="*****" passwdValidTo="1970-01-01T00:00:01" port="-1" type="vnc"/>                 <emulator>/usr/bin/qemu-system-ppc64</emulator>                 <memballoon model="virtio"/>                 <controller index="0" type="scsi">                         <address type="spapr-vio"/>                 </controller>                 <controller index="1" model="virtio-scsi" type="scsi"/>                 <video>                         <model heads="1" type="vga" vram="32768"/>                 </video>                 <interface type="bridge">                         <mac address="00:1a:4a:65:ca:b2"/>                         <model type="virtio"/>                         <source bridge="ovirtmgmt"/>                         <filterref filter="vdsm-no-mac-spoofing"/>                         <link state="up"/>                 </interface>                 <disk device="cdrom" snapshot="no" type="file">                         <address bus="0" controller="0" target="0" type="drive" unit="0"/>                         <source file="" startupPolicy="optional"/>                         <target bus="scsi" dev="sda"/>                         <readonly/>                         <serial/>                 </disk>                 <disk device="disk" snapshot="no" type="file">                         <source file="/rhev/data-center/mnt/str-02.rhev.lab.eng.brq.redhat.com:_mnt_export_nfs_150_nfs04/efd2a9ce-6417-44e9-ac59-bb577f22bbc3/images/4f6be340-f7b1-4b78-9aa3-7390ffd6bec8/e4f6d99b-c94c-4ae9-8bd6-5212a1d4e9df"/>                         <target bus="virtio" dev="vda"/>                         <serial>4f6be340-f7b1-4b78-9aa3-7390ffd6bec8</serial>                         <boot order="1"/>                         <driver cache="none" error_policy="stop" io="threads" name="qemu" type="raw"/>                 </disk>         </devices>         <os>                 <type arch="ppc64" machine="pseries">hvm</type>         </os>         <clock adjustment="0" offset="variable">                 <timer name="rtc" tickpolicy="catchup"/>         </clock>         <cpu>                 <topology cores="1" sockets="1" threads="1"/>         </cpu>         <qemu:commandline>                 <qemu:arg value="-usbdevice"/>                 <qemu:arg value="keyboard"/>         </qemu:commandline> </domain> Thread-77::DEBUG::2014-01-23 15:43:47,566::libvirtconnection::124::root::(wrapper) Unknown libvirterror: ecode: 1 edom: 10 level: 2 message: internal error: process exited while connecting to monitor: "kvm" accelerator does not exist. No accelerator found! KVM not supported for this target Thread-77::DEBUG::2014-01-23 15:43:47,567::vm::2247::vm.Vm::(_startUnderlyingVm) vmId=`a5409fe7-8054-46ce-91c2-2d565e7edc5b`::_ongoingCreations released Thread-77::ERROR::2014-01-23 15:43:47,567::vm::2273::vm.Vm::(_startUnderlyingVm) vmId=`a5409fe7-8054-46ce-91c2-2d565e7edc5b`::The vm start process failed Traceback (most recent call last):   File "/usr/share/vdsm/vm.py", line 2233, in _startUnderlyingVm     self._run()   File "/usr/share/vdsm/vm.py", line 3164, in _run     self._connection.createXML(domxml, flags),   File "/usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py", line 92, in wrapper     ret = f(*args, **kwargs)   File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2920, in createXML     if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirtError: internal error: process exited while connecting to monitor: "kvm" accelerator does not exist. No accelerator found! KVM not supported for this target Extraction of the capabilities related to this:   <guest>     <os_type>hvm</os_type>     <arch name='ppc'>       <wordsize>32</wordsize>       <emulator>/usr/bin/qemu-system-ppc</emulator>       <machine>g3beige</machine>       <machine>prep</machine>       <machine>mpc8544ds</machine>       <machine>mac99</machine>       <machine>ppce500</machine>       <machine>virtex-ml507</machine>       <machine>bamboo</machine>       <machine>taihu</machine>       <machine>ref405ep</machine>       <machine>none</machine>       <domain type='qemu'>       </domain>     </arch>     <features>       <cpuselection/>       <deviceboot/>     </features>   </guest>   <guest>     <os_type>hvm</os_type>     <arch name='ppc64'>       <wordsize>64</wordsize>       <emulator>/usr/bin/qemu-system-ppc64</emulator>       <machine>mac99</machine>       <machine>prep</machine>       <machine>mpc8544ds</machine>       <machine>g3beige</machine>       <machine>ppce500</machine>       <machine>virtex-ml507</machine>       <machine>pseries</machine>       <machine>bamboo</machine>       <machine>taihu</machine>       <machine>ref405ep</machine>       <machine>none</machine>       <domain type='qemu'>       </domain>     </arch>     <features>       <cpuselection/>       <deviceboot/>     </features>   </guest> <pre class="moz-signature" cols="72">-- Regards, Vinzenz Feenstra | Senior Software Engineer RedHat Engineering Virtualization R & D Phone: +420 532 294 625 IRC: vfeenstr or evilissimo Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com</pre> </body> </html> --------------070509070905070907070200--

3 3

[Engine-devel] webadmin (vs) rest-api & transition plan
by Sven Kieske 10 Feb '14

10 Feb '14

Hi devs, I want to talk about the current development style and the (somewhat) planned transition from webadmin today to a webadmin which uses REST for communication. I honestly don't see how this goal can be achieved, given the current development pattern, but I may be wrong. e.g. this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1061131 it asks for a feature being available in GUI/webadmin. I'm pretty sure this gets implemented and adds another feature to the list which is not implemented via REST, thus leading to an even higher gap between REST and webadmin. Following this pattern will make the goal of using REST everywhere not easier to achieve. If you really want to build everything upon REST, or at least, transition everything to REST, there should be a policy that new features should be developed for REST access first. I don't know if such a policy is already in place and I know it will take some time for the transition, but what I observe leads me to the conclusion that the gap gets greater. What do you think? Are there any plans inside RH which I don't know regarding this transition? Maybe something you can share with your REST-Users? -- 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 2

[Engine-devel] oVirt test day tomorrow
by Doron Fediuck 10 Feb '14

10 Feb '14

Just a reminder that tomorrow we plan to have oVirt 3.4 2nd test day. More details coming soon.

1 0

Re: [Engine-devel] ovirt-engine_master_create_rpms is experiencing some weird issue
by Eyal Edri 09 Feb '14

09 Feb '14

it looks like it's really failing on creating the rpms as well : http://jenkins.ovirt.org/job/ovirt-engine_master_create_rpms/1471/label=cen… on webadmin. can someone have a look? eyal. ----- Original Message ----- > From: "Sandro Bonazzola" <sbonazzo(a)redhat.com> > To: "infra" <infra(a)ovirt.org> > Sent: Friday, February 7, 2014 10:00:02 AM > Subject: ovirt-engine_master_create_rpms is experiencing some weird issue > > Hi, > http://jenkins.ovirt.org/job/ovirt-engine_master_create_rpms is experiencing > some weird issue. > pending #1454 (pending—Waiting for next available executor) > Nothing is currently running on jenkins so all executors are available. > Build Now doesn't work > Abort execution doesn't work > Rebuild last doesn't work > > Can you take a look? > Thanks > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra >

2 2

[Engine-devel] FOSDEM slides + recordings available
by Doron Fediuck 09 Feb '14

09 Feb '14

http://www.ovirt.org/FOSDEM_2014#Sessions I will continue to update with recordings (and last slides) as it becomes available. This is also a good chance to thank everyone involved. People who practiced, spoke, volunteered for stand shifts, Video handling, helping with the oVirt-live, carrying maps, laptops, handout-sheets, poster-sign to/from UBL and other logistics. Special thanks to Joop, René, Jorick, Robert and Alexander who joined us in ULB . We got a big and very positive exposure for oVirt, which as you'll be able to hear is getting a lot of community attention now. See you in FOSDEM 2015 ;) Doron

1 0

[Engine-devel] [ANN] oVirt 3.4.0 beta2 is now available
by Sandro Bonazzola 07 Feb '14

07 Feb '14

The oVirt team is pleased to announce that the 3.4.0 second beta release is now available for testing. Release notes and information on the changes for this update are still being worked on and will be available soon on the wiki[1]. Please ensure to follow install instruction from release notes if you're going to test it. The existing repository ovirt-3.4.0-prerelease has been updated for delivering this beta and future refreshes until release candidate. A new oVirt Node build will be available soon as well. You're welcome to join us testing this beta release in next week test day [2] scheduled for 2014-02-11! [1] http://www.ovirt.org/OVirt_3.4.0_release_notes [2] http://www.ovirt.org/OVirt_3.4_Test_Day -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

[Engine-devel] ATTN: UICommon: new dialog model attribute - HelpTag
by Greg Sheremeta 07 Feb '14

07 Feb '14

Hi all, To make it easier to support context-sensitive help in webadmin and userportal, we added a model attribute called HelpTag to all models. from now on: for any new dialog that you create, please remember to do the following: - add a call to setHelpTag before after the call to setHashName in the new model. - add the relevant dialog meta-data in HelpTag.java [We didn't make it a constructor argument because that's quite invasive] I updated all the current models in [1] to have this new call. This is effective immediately in 'master' - we intend to backport this functionality to ovirt-engine-3.4 very soon. Greg [1] http://gerrit.ovirt.org/#/c/21052/ Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gshereme(a)redhat.com

1 0

[Engine-devel] Problem creating hosts.
by Sérgio Ribeiro 05 Feb '14

05 Feb '14

--_46FF3AC8-76AD-4C8E-803D-18759F7CEFEB_ Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" SeKAmW0gbmV3YmllIGluIG92aXJ0IGFuZCBhZnRlciBpbnN0YWxsaW5nIG92aXJ0LCB3aXRoIGNv bWFuZCBlbmdpbmUtc2V0dXAsIA0KaSBnbyB0byBsb2NhbGhvc3Qvb3ZpcnQtZW5naW5lIGFuZCBp IGxvZyBvbiB0aGUgd2VicGFnZS4gT24gZGF0YSBjZW50ZXIgb25seSBhcHBlYXJzIGEgZGVmYXVs dCBkYXRhLWNlbnRlciB3aXRoIG5vIGhvc3RzLiBpIHRyaWUgdG8gY3JlYXRlIGEgaG9zdCBhbmQg YXBwZWFycyBuYSBlcnJvciBiZWNhdXNlIHRoZSBuYW1lIGFuZCBhZGRyZXNzIG9mIHRoZSBob3N0 LiBpdHMgYSBsb2NhbCBtYWNoaW5lIGZvciB0ZXN0cyB3aXRoIG5vIGRvbWFpbi4NCnRoZSBjb25m aWcgdGhhdCBpIHVzZSBpcyBuYW1lOmhvc3QxLmxvY2FsZG9tYWluLCBhZGRyZXNzOiAxOTIuMTY4 LjIuMSwgYW5kIGkgY3JlYXRlZCB0aGlzIGNvbmZpZyBvbiBldGMvaG9zdHMgZmlsZS4NCg0KY2Fu IHlvdSBoZWxwIG1lPw0KDQpCZXN0IHJlZ2FyZHMNCg0KDQoNCg0KDQoNCg0KRW52aWFkbyBkZSBD b3JyZWlvIGRvIFdpbmRvd3M= --_46FF3AC8-76AD-4C8E-803D-18759F7CEFEB_ Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" CjxodG1sPgo8aGVhZD4KPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJXaW5kb3dzIE1h aWwgMTcuNS45NjAwLjIwMzE1Ij4KPHN0eWxlIGRhdGEtZXh0ZXJuYWxzdHlsZT0idHJ1ZSI+PCEt LQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFy YWdyYXBoIHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdodDowaW47Cm1hcmdpbi1ib3R0b206 MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbCB7Cm1hcmdpbjowaW47Cm1hcmdpbi1ib3R0 b206LjAwMDFwdDsKfQpwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIGxpLk1zb0xpc3RQYXJh Z3JhcGhDeFNwRmlyc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCAKcC5Nc29MaXN0 UGFyYWdyYXBoQ3hTcE1pZGRsZSwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIGRpdi5N c29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgCnAuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBs aS5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3Qg ewptYXJnaW4tdG9wOjBpbjsKbWFyZ2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTowaW47Cm1h cmdpbi1sZWZ0Oi41aW47Cm1hcmdpbi1ib3R0b206LjAwMDFwdDsKbGluZS1oZWlnaHQ6MTE1JTsK fQotLT48L3N0eWxlPjwvaGVhZD4KPGJvZHkgZGlyPSJsdHIiPgo8ZGl2IGRhdGEtZXh0ZXJuYWxz dHlsZT0iZmFsc2UiIGRpcj0ibHRyIiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDYWxpYnJpJywgJ1Nl Z29lIFVJJywgJ01laXJ5bycsICdNaWNyb3NvZnQgWWFIZWkgVUknLCAnTWljcm9zb2Z0IEpoZW5n SGVpIFVJJywgJ01hbGd1biBHb3RoaWMnLCAnc2Fucy1zZXJpZic7Zm9udC1zaXplOjEycHQ7Ij4K PGRpdj5J4oCZbSBuZXdiaWUgaW4gb3ZpcnQgYW5kIGFmdGVyIGluc3RhbGxpbmcgb3ZpcnQsIHdp dGggY29tYW5kIGVuZ2luZS1zZXR1cCwgPGJyPmkgZ28gdG8gbG9jYWxob3N0L292aXJ0LWVuZ2lu ZSBhbmQgaSBsb2cgb24gdGhlIHdlYnBhZ2UuIE9uIGRhdGEgY2VudGVyIG9ubHkgYXBwZWFycyBh IGRlZmF1bHQgZGF0YS1jZW50ZXIgd2l0aCBubyBob3N0cy4gaSB0cmllIHRvIGNyZWF0ZSBhIGhv c3QgYW5kIGFwcGVhcnMgbmEgZXJyb3IgYmVjYXVzZSZuYnNwO3RoZSBuYW1lIGFuZCBhZGRyZXNz IG9mIHRoZSBob3N0LiBpdHMgYSBsb2NhbCBtYWNoaW5lIGZvciB0ZXN0cyB3aXRoIG5vIGRvbWFp bi48YnI+dGhlIGNvbmZpZyB0aGF0IGkgdXNlIGlzIG5hbWU6aG9zdDEubG9jYWxkb21haW4sIGFk ZHJlc3M6IDE5Mi4xNjguMi4xLCBhbmQgaSBjcmVhdGVkIHRoaXMgY29uZmlnIG9uIGV0Yy9ob3N0 cyBmaWxlLjxicj48YnI+Y2FuIHlvdSBoZWxwIG1lPzxicj48YnI+QmVzdCByZWdhcmRzPGJyPjxi cj48L2Rpdj48ZGl2IGRhdGEtc2lnbmF0dXJlYmxvY2s9InRydWUiPjxkaXY+PGJyPjwvZGl2Pjxk aXY+RW52aWFkbyBkZSBDb3JyZWlvIGRvIFdpbmRvd3M8L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rp dj4KCgo8L2Rpdj4KPC9ib2R5Pgo8L2h0bWw+Cg== --_46FF3AC8-76AD-4C8E-803D-18759F7CEFEB_--

3 2