[Engine-devel] [oVirt/RHEV 3.4 Localization Question #16] Strings with resource ID "ActionGroup___"
by Yuko Katabami
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, <br>
<br>
I am a Brisbane-based translator working on oVirt 3.4 localization
project along with 5 other translators.<br>
Our localization cycle is just kicked off and I would like to post
our questions here, just like I did for 3.3.<br>
It would be appreciated if you could help us.<br>
<br>
Here is our first question.<br>
<br>
<b>File:</b><b> </b>LocalizedEnums<b><br>
</b><b>Resource ID:</b><b> </b>starting with "ActionGroup___"<b><br>
</b><b>Strings:</b><b> </b>including <br>
Assign vNIC Profile to Template<br>
Assign vNIC Profile to VM<br>
Assign vNIC Profile to VM<br>
Access Image Storage Domains<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<b>Question:</b> In this file, there are number of strings with the
resource ID starting with "ActionGroup___". <br>
Could you please let me know the usage?<br>
Are these actions used to replace variable in strings such as
"Cannot ${action} ${type}"?<br>
Or is it more like action buttons?<br>
Translation may vary depending on the usage/context and it would be
helpful if you could give us some extra information.<br>
<br>
Kind regards,<br>
<br>
Yuko<br>
</body>
</html>
--------------020603010501060100010609--
10 years, 9 months
[Engine-devel] Spice proxy test day support
by Doron Fediuck
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).
10 years, 9 months
[Engine-devel] [ovirt-testday] Fake PPC Support - Feedback
by Vinzenz Feenstra
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,<br>
<br>
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:<br>
<b><br>
libvirtError: internal error: process exited while connecting to
monitor: "kvm" accelerator does not exist.</b><b><br>
</b><b>
No accelerator found!</b><b><br>
</b><b>
KVM not supported for this target</b><b><br>
</b><b>
</b><br>
Which does not make much sense though. Since it should not try to
use 'kvm'. And I am not really sure why it does.<br>
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.<br>
<br>
Here's the part of the log which prints the generated DomainXML:<br>
<br>
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"?><br>
<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>><br>
<name>asdfasd</name><br>
<uuid>a5409fe7-8054-46ce-91c2-2d565e7edc5b</uuid><br>
<memory>524288</memory><br>
<currentMemory>524288</currentMemory><br>
<vcpu current="1">1</vcpu><br>
<memtune><br>
<min_guarantee>524288</min_guarantee><br>
</memtune><br>
<devices><br>
<channel type="unix"><br>
<target name="com.redhat.rhevm.vdsm"
type="virtio"/><br>
<source mode="bind"
path="/var/lib/libvirt/qemu/channels/a5409fe7-8054-46ce-91c2-2d565e7edc5b.com.redhat.rhevm.vdsm"/><br>
</channel><br>
<channel type="unix"><br>
<target name="org.qemu.guest_agent.0"
type="virtio"/><br>
<source mode="bind"
path="/var/lib/libvirt/qemu/channels/a5409fe7-8054-46ce-91c2-2d565e7edc5b.org.qemu.guest_agent.0"/><br>
</channel><br>
<input bus="usb" type="tablet"/><br>
<graphics autoport="yes" keymap="en-us"
listen="0" passwd="*****" passwdValidTo="1970-01-01T00:00:01"
port="-1" type="vnc"/><br>
<emulator>/usr/bin/qemu-system-ppc64</emulator><br>
<memballoon model="virtio"/><br>
<controller index="0" type="scsi"><br>
<address type="spapr-vio"/><br>
</controller><br>
<controller index="1" model="virtio-scsi"
type="scsi"/><br>
<video><br>
<model heads="1" type="vga"
vram="32768"/><br>
</video><br>
<interface type="bridge"><br>
<mac address="00:1a:4a:65:ca:b2"/><br>
<model type="virtio"/><br>
<source bridge="ovirtmgmt"/><br>
<filterref
filter="vdsm-no-mac-spoofing"/><br>
<link state="up"/><br>
</interface><br>
<disk device="cdrom" snapshot="no"
type="file"><br>
<address bus="0" controller="0"
target="0" type="drive" unit="0"/><br>
<source file=""
startupPolicy="optional"/><br>
<target bus="scsi" dev="sda"/><br>
<readonly/><br>
<serial/><br>
</disk><br>
<disk device="disk" snapshot="no" type="file"><br>
<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"/><br>
<target bus="virtio" dev="vda"/><br>
<serial>4f6be340-f7b1-4b78-9aa3-7390ffd6bec8</serial><br>
<boot order="1"/><br>
<driver cache="none" error_policy="stop"
io="threads" name="qemu" type="raw"/><br>
</disk><br>
</devices><br>
<os><br>
<type arch="ppc64"
machine="pseries">hvm</type><br>
</os><br>
<clock adjustment="0" offset="variable"><br>
<timer name="rtc" tickpolicy="catchup"/><br>
</clock><br>
<cpu><br>
<topology cores="1" sockets="1" threads="1"/><br>
</cpu><br>
<qemu:commandline><br>
<qemu:arg value="-usbdevice"/><br>
<qemu:arg value="keyboard"/><br>
</qemu:commandline><br>
</domain><br>
<br>
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.<br>
No accelerator found!<br>
KVM not supported for this target<br>
<br>
Thread-77::DEBUG::2014-01-23
15:43:47,567::vm::2247::vm.Vm::(_startUnderlyingVm)
vmId=`a5409fe7-8054-46ce-91c2-2d565e7edc5b`::_ongoingCreations
released<br>
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<br>
Traceback (most recent call last):<br>
File "/usr/share/vdsm/vm.py", line 2233, in _startUnderlyingVm<br>
self._run()<br>
File "/usr/share/vdsm/vm.py", line 3164, in _run<br>
self._connection.createXML(domxml, flags),<br>
File
"/usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py", line
92, in wrapper<br>
ret = f(*args, **kwargs)<br>
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2920,
in createXML<br>
if ret is None:raise libvirtError('virDomainCreateXML() failed',
conn=self)<br>
libvirtError: internal error: process exited while connecting to
monitor: "kvm" accelerator does not exist.<br>
No accelerator found!<br>
KVM not supported for this target<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Extraction of the capabilities related to this:<br>
<br>
<guest><br>
<os_type>hvm</os_type><br>
<arch name='ppc'><br>
<wordsize>32</wordsize><br>
<emulator>/usr/bin/qemu-system-ppc</emulator><br>
<machine>g3beige</machine><br>
<machine>prep</machine><br>
<machine>mpc8544ds</machine><br>
<machine>mac99</machine><br>
<machine>ppce500</machine><br>
<machine>virtex-ml507</machine><br>
<machine>bamboo</machine><br>
<machine>taihu</machine><br>
<machine>ref405ep</machine><br>
<machine>none</machine><br>
<domain type='qemu'><br>
</domain><br>
</arch><br>
<features><br>
<cpuselection/><br>
<deviceboot/><br>
</features><br>
</guest><br>
<br>
<guest><br>
<os_type>hvm</os_type><br>
<arch name='ppc64'><br>
<wordsize>64</wordsize><br>
<emulator>/usr/bin/qemu-system-ppc64</emulator><br>
<machine>mac99</machine><br>
<machine>prep</machine><br>
<machine>mpc8544ds</machine><br>
<machine>g3beige</machine><br>
<machine>ppce500</machine><br>
<machine>virtex-ml507</machine><br>
<machine>pseries</machine><br>
<machine>bamboo</machine><br>
<machine>taihu</machine><br>
<machine>ref405ep</machine><br>
<machine>none</machine><br>
<domain type='qemu'><br>
</domain><br>
</arch><br>
<features><br>
<cpuselection/><br>
<deviceboot/><br>
</features><br>
</guest><br>
<br>
<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--
10 years, 9 months
[Engine-devel] webadmin (vs) rest-api & transition plan
by Sven Kieske
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
10 years, 9 months
[Engine-devel] FOSDEM slides + recordings available
by Doron Fediuck
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
10 years, 9 months
[Engine-devel] [ANN] oVirt 3.4.0 beta2 is now available
by Sandro Bonazzola
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
10 years, 9 months
[Engine-devel] ATTN: UICommon: new dialog model attribute - HelpTag
by Greg Sheremeta
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
10 years, 9 months
[Engine-devel] Problem creating hosts.
by Sérgio Ribeiro
--_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_--
10 years, 9 months
