From mkolesni at redhat.com Mon Nov 11 02:49:34 2013 Content-Type: multipart/mixed; boundary="===============5282216648594801436==" MIME-Version: 1.0 From: Mike Kolesnik To: devel at ovirt.org Subject: [Engine-devel] Custom properties per device + vNIC profile = not working (< 3.3) Date: Mon, 11 Nov 2013 02:49:33 -0500 Message-ID: <1480148973.29121435.1384156173916.JavaMail.root@redhat.com> In-Reply-To: 1460357966.29104754.1384153989435.JavaMail.root@redhat.com --===============5282216648594801436== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ------=3D_Part_29121434_1238593392.1384156173914 Content-Type: text/plain; charset=3Dutf-8 Content-Transfer-Encoding: 7bit Hi, = I came across a situation where I wanted to define custom properties on a v= NIC profile sitting under a network in a 3.2 data center. = >From what I saw the configuration value for custom properties (CustomDevic= eProperties) is split into 4, one per each version (3.0, 3.1, 3.2, 3.3). = Since vNIC profile is located under the DC tree, it takes the DC version - = 3.2 in this specific case. = I tried to set the config value for 3.2 but got: = $ engine-config -s CustomDeviceProperties=3D"{type=3Dinterface;prop=3D{myPr= op=3D[a-zA-Z0-9-]+}}" --cver=3D3.2 = Cannot set value {type=3Dinterface;prop=3D{myProp=3D[a-zA-Z0-9-]+}} to key = CustomDeviceProperties. Device custom properties are not supported in versi= on 3.2 = This is already not very good, since in a 3.2 DC there can be 3.3 clusters = with 3.3 hosts that do support custom device properties. = I also tried to alter the config value in the DB directly, but the custom p= roperties code ignored it since custom properties are not supported in 3.2. = So, de facto, I have no reasonable way as a user to define custom device pr= operties to use for my vNIC profiles in DC < 3.3. = I opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=3D1028757 for = this, however I also want to discuss the situation: = 1. As a user, I can't set custom properties for level < 3.3 which is not go= od. = Removing the blocking, and loading custom properties for all versions would= fix the bug and allow using custom device properties for older versions, t= he reasonable place to block this would be running a VM (or plugging a devi= ce). = Basically this is the lesser issue.. = 2. I just don't see the added value of splitting the definition of the prop= erties per level.. = The custom properties are extensions which might or might not be available = to a certain VM, I don't see how having different sets of custom properties= per version (what version, DC version, cluster version?) would make any di= fference - either the VM can utilize the extension given some state of the = system, or it can't, but the determining factor is not the version but rath= er the availability of the extension. = For example, I can have a hook for vNIC altering some property installed on= host A and not host B, if the VM runs on host A it will get this capabilit= y and on host B it won't, regardless the DC version the VM is in. = This is not to say we shouldn't block custom properties on the engine-VDSM = API level since it's only available since 3.3, but this is handled by anoth= er config value (SupportCustomDeviceProperties) which is not alterable by t= he user. = So basically, I think splitting the value per version is over complication = and see no added value to the users, just more maintenance should they choo= se to use this feature. = Your thoughts please. = Regards, = Mike = ------=3D_Part_29121434_1238593392.1384156173914 Content-Type: text/html; charset=3Dutf-8 Content-Transfer-Encoding: quoted-printable
Hi,

I came across a situation where I wanted to define custom properties on a = =3D vNIC profile sitting under a network in a 3.2 data center.
Fr= =3D om what I saw the configuration value for custom properties (CustomDevicePr= =3D operties) is split into 4, one per each version (3.0, 3.1, 3.2, 3.3).
Since vNIC profile is located under the DC tree, it takes the DC v= =3D ersion - 3.2 in this specific case.

I tried to= =3D set the config value for 3.2 but got:
$ engine-config -s Cus= =3D tomDeviceProperties=3D3D"{type=3D3Dinterface;prop=3D3D{myProp=3D3D[a-zA-Z0-= 9-]+}}" =3D --cver=3D3D3.2
Cannot set value {type=3D3Dinterface;prop=3D3D{myProp=3D3= D[a-zA-Z=3D 0-9-]+}} to key CustomDeviceProperties. Device custom properties are not su= =3D pported in version 3.2

This is already not very good, sin= =3D ce in a 3.2 DC there can be 3.3 clusters with 3.3 hosts that do support cus= =3D tom device properties.

I also tried to alter t= =3D he config value in the DB directly, but the custom properties code ignored = =3D it since custom properties are not supported in 3.2.
So, de f= =3D acto, I have no reasonable way as a user to define custom device properties= =3D to use for my vNIC profiles in DC < 3.3.

I= =3D opened the bug https://bugzilla.redhat.com/show_bug.cgi?id=3D3D1028757 for this= , =3D however I also want to discuss the situation:

1. A= =3D s a user, I can't set custom properties for level < 3.3 which is not goo= =3D d.
    Removing the blocking, and loading cust= =3D om properties for all versions would fix the bug and allow using custom dev= =3D ice properties for older versions, the reasonable place to block this would= =3D be running a VM (or plugging a device).
    B= =3D asically this is the lesser issue..

2. I just = =3D don't see the added value of splitting the definition of the properties per= =3D level..
    The custom properties are extensi= =3D ons which might or might not be available to a certain VM, I don't see how = =3D having different sets of custom properties per version (what version, DC ve= =3D rsion, cluster version?) would make any difference - either the VM can util= =3D ize the extension given some state of the system, or it can't, but the dete= =3D rmining factor is not the version but rather the availability of the extens= =3D ion.
    For example, I can have a hook for vN= =3D IC altering some property installed on host A and not host B, if the VM run= =3D s on host A it will get this capability and on host B it won't, regardless = =3D the DC version the VM is in.

   = =3D ; This is not to say we shouldn't block custom properties on the engine-VDS= =3D M API level since it's only available since 3.3, but this is handled by ano= =3D ther config value (SupportCustomDeviceProperties) which is not alterable by= =3D the user.
    So basically, I think splitting= =3D the value per version is over complication and see no added value to the u= =3D sers, just more maintenance should they choose to use this feature.

Your thoughts please.

Regards,
Mike

------=3D_Part_29121434_1238593392.1384156173914-- --===============5282216648594801436== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" LS0tLS0tPV9QYXJ0XzI5MTIxNDM0XzEyMzg1OTMzOTIuMTM4NDE1NjE3MzkxNApDb250ZW50LVR5 cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9dXRmLTgKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzog N2JpdAoKSGksIAoKSSBjYW1lIGFjcm9zcyBhIHNpdHVhdGlvbiB3aGVyZSBJIHdhbnRlZCB0byBk ZWZpbmUgY3VzdG9tIHByb3BlcnRpZXMgb24gYSB2TklDIHByb2ZpbGUgc2l0dGluZyB1bmRlciBh IG5ldHdvcmsgaW4gYSAzLjIgZGF0YSBjZW50ZXIuIAo+RnJvbSB3aGF0IEkgc2F3IHRoZSBjb25m aWd1cmF0aW9uIHZhbHVlIGZvciBjdXN0b20gcHJvcGVydGllcyAoQ3VzdG9tRGV2aWNlUHJvcGVy dGllcykgaXMgc3BsaXQgaW50byA0LCBvbmUgcGVyIGVhY2ggdmVyc2lvbiAoMy4wLCAzLjEsIDMu MiwgMy4zKS4gClNpbmNlIHZOSUMgcHJvZmlsZSBpcyBsb2NhdGVkIHVuZGVyIHRoZSBEQyB0cmVl LCBpdCB0YWtlcyB0aGUgREMgdmVyc2lvbiAtIDMuMiBpbiB0aGlzIHNwZWNpZmljIGNhc2UuIAoK SSB0cmllZCB0byBzZXQgdGhlIGNvbmZpZyB2YWx1ZSBmb3IgMy4yIGJ1dCBnb3Q6IAokIGVuZ2lu ZS1jb25maWcgLXMgQ3VzdG9tRGV2aWNlUHJvcGVydGllcz0ie3R5cGU9aW50ZXJmYWNlO3Byb3A9 e215UHJvcD1bYS16QS1aMC05LV0rfX0iIC0tY3Zlcj0zLjIgCkNhbm5vdCBzZXQgdmFsdWUge3R5 cGU9aW50ZXJmYWNlO3Byb3A9e215UHJvcD1bYS16QS1aMC05LV0rfX0gdG8ga2V5IEN1c3RvbURl dmljZVByb3BlcnRpZXMuIERldmljZSBjdXN0b20gcHJvcGVydGllcyBhcmUgbm90IHN1cHBvcnRl ZCBpbiB2ZXJzaW9uIDMuMiAKClRoaXMgaXMgYWxyZWFkeSBub3QgdmVyeSBnb29kLCBzaW5jZSBp biBhIDMuMiBEQyB0aGVyZSBjYW4gYmUgMy4zIGNsdXN0ZXJzIHdpdGggMy4zIGhvc3RzIHRoYXQg ZG8gc3VwcG9ydCBjdXN0b20gZGV2aWNlIHByb3BlcnRpZXMuIAoKSSBhbHNvIHRyaWVkIHRvIGFs dGVyIHRoZSBjb25maWcgdmFsdWUgaW4gdGhlIERCIGRpcmVjdGx5LCBidXQgdGhlIGN1c3RvbSBw cm9wZXJ0aWVzIGNvZGUgaWdub3JlZCBpdCBzaW5jZSBjdXN0b20gcHJvcGVydGllcyBhcmUgbm90 IHN1cHBvcnRlZCBpbiAzLjIuIApTbywgZGUgZmFjdG8sIEkgaGF2ZSBubyByZWFzb25hYmxlIHdh eSBhcyBhIHVzZXIgdG8gZGVmaW5lIGN1c3RvbSBkZXZpY2UgcHJvcGVydGllcyB0byB1c2UgZm9y IG15IHZOSUMgcHJvZmlsZXMgaW4gREMgPCAzLjMuIAoKSSBvcGVuZWQgdGhlIGJ1ZyBodHRwczov L2J1Z3ppbGxhLnJlZGhhdC5jb20vc2hvd19idWcuY2dpP2lkPTEwMjg3NTcgZm9yIHRoaXMsIGhv d2V2ZXIgSSBhbHNvIHdhbnQgdG8gZGlzY3VzcyB0aGUgc2l0dWF0aW9uOiAKCjEuIEFzIGEgdXNl ciwgSSBjYW4ndCBzZXQgY3VzdG9tIHByb3BlcnRpZXMgZm9yIGxldmVsIDwgMy4zIHdoaWNoIGlz IG5vdCBnb29kLiAKUmVtb3ZpbmcgdGhlIGJsb2NraW5nLCBhbmQgbG9hZGluZyBjdXN0b20gcHJv cGVydGllcyBmb3IgYWxsIHZlcnNpb25zIHdvdWxkIGZpeCB0aGUgYnVnIGFuZCBhbGxvdyB1c2lu ZyBjdXN0b20gZGV2aWNlIHByb3BlcnRpZXMgZm9yIG9sZGVyIHZlcnNpb25zLCB0aGUgcmVhc29u YWJsZSBwbGFjZSB0byBibG9jayB0aGlzIHdvdWxkIGJlIHJ1bm5pbmcgYSBWTSAob3IgcGx1Z2dp bmcgYSBkZXZpY2UpLiAKQmFzaWNhbGx5IHRoaXMgaXMgdGhlIGxlc3NlciBpc3N1ZS4uIAoKMi4g SSBqdXN0IGRvbid0IHNlZSB0aGUgYWRkZWQgdmFsdWUgb2Ygc3BsaXR0aW5nIHRoZSBkZWZpbml0 aW9uIG9mIHRoZSBwcm9wZXJ0aWVzIHBlciBsZXZlbC4uIApUaGUgY3VzdG9tIHByb3BlcnRpZXMg YXJlIGV4dGVuc2lvbnMgd2hpY2ggbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZSB0byBh IGNlcnRhaW4gVk0sIEkgZG9uJ3Qgc2VlIGhvdyBoYXZpbmcgZGlmZmVyZW50IHNldHMgb2YgY3Vz dG9tIHByb3BlcnRpZXMgcGVyIHZlcnNpb24gKHdoYXQgdmVyc2lvbiwgREMgdmVyc2lvbiwgY2x1 c3RlciB2ZXJzaW9uPykgd291bGQgbWFrZSBhbnkgZGlmZmVyZW5jZSAtIGVpdGhlciB0aGUgVk0g Y2FuIHV0aWxpemUgdGhlIGV4dGVuc2lvbiBnaXZlbiBzb21lIHN0YXRlIG9mIHRoZSBzeXN0ZW0s IG9yIGl0IGNhbid0LCBidXQgdGhlIGRldGVybWluaW5nIGZhY3RvciBpcyBub3QgdGhlIHZlcnNp b24gYnV0IHJhdGhlciB0aGUgYXZhaWxhYmlsaXR5IG9mIHRoZSBleHRlbnNpb24uIApGb3IgZXhh bXBsZSwgSSBjYW4gaGF2ZSBhIGhvb2sgZm9yIHZOSUMgYWx0ZXJpbmcgc29tZSBwcm9wZXJ0eSBp bnN0YWxsZWQgb24gaG9zdCBBIGFuZCBub3QgaG9zdCBCLCBpZiB0aGUgVk0gcnVucyBvbiBob3N0 IEEgaXQgd2lsbCBnZXQgdGhpcyBjYXBhYmlsaXR5IGFuZCBvbiBob3N0IEIgaXQgd29uJ3QsIHJl Z2FyZGxlc3MgdGhlIERDIHZlcnNpb24gdGhlIFZNIGlzIGluLiAKClRoaXMgaXMgbm90IHRvIHNh eSB3ZSBzaG91bGRuJ3QgYmxvY2sgY3VzdG9tIHByb3BlcnRpZXMgb24gdGhlIGVuZ2luZS1WRFNN IEFQSSBsZXZlbCBzaW5jZSBpdCdzIG9ubHkgYXZhaWxhYmxlIHNpbmNlIDMuMywgYnV0IHRoaXMg aXMgaGFuZGxlZCBieSBhbm90aGVyIGNvbmZpZyB2YWx1ZSAoU3VwcG9ydEN1c3RvbURldmljZVBy b3BlcnRpZXMpIHdoaWNoIGlzIG5vdCBhbHRlcmFibGUgYnkgdGhlIHVzZXIuIApTbyBiYXNpY2Fs bHksIEkgdGhpbmsgc3BsaXR0aW5nIHRoZSB2YWx1ZSBwZXIgdmVyc2lvbiBpcyBvdmVyIGNvbXBs aWNhdGlvbiBhbmQgc2VlIG5vIGFkZGVkIHZhbHVlIHRvIHRoZSB1c2VycywganVzdCBtb3JlIG1h aW50ZW5hbmNlIHNob3VsZCB0aGV5IGNob29zZSB0byB1c2UgdGhpcyBmZWF0dXJlLiAKCllvdXIg dGhvdWdodHMgcGxlYXNlLiAKClJlZ2FyZHMsIApNaWtlIAoKCi0tLS0tLT1fUGFydF8yOTEyMTQz NF8xMjM4NTkzMzkyLjEzODQxNTYxNzM5MTQKQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQoKPGh0 bWw+PGJvZHk+PGRpdiBzdHlsZT0zRCJmb250LWZhbWlseTogdGltZXMgbmV3IHJvbWFuLCBuZXcg eW9yaywgdGltZXMsIHNlPQpyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDAiPjxk aXY+SGksPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY9Cj5JIGNhbWUgYWNyb3NzIGEgc2l0 dWF0aW9uIHdoZXJlIEkgd2FudGVkIHRvIGRlZmluZSBjdXN0b20gcHJvcGVydGllcyBvbiBhID0K dk5JQyBwcm9maWxlIHNpdHRpbmcgdW5kZXIgYSBuZXR3b3JrIGluIGEgMy4yIGRhdGEgY2VudGVy Ljxicj48L2Rpdj48ZGl2PkZyPQpvbSB3aGF0IEkgc2F3IHRoZSBjb25maWd1cmF0aW9uIHZhbHVl IGZvciBjdXN0b20gcHJvcGVydGllcyAoQ3VzdG9tRGV2aWNlUHI9Cm9wZXJ0aWVzKSBpcyBzcGxp dCBpbnRvIDQsIG9uZSBwZXIgZWFjaCB2ZXJzaW9uICgzLjAsIDMuMSwgMy4yLCAzLjMpLjxicj48 Lz0KZGl2PjxkaXY+U2luY2Ugdk5JQyBwcm9maWxlIGlzIGxvY2F0ZWQgdW5kZXIgdGhlIERDIHRy ZWUsIGl0IHRha2VzIHRoZSBEQyB2PQplcnNpb24gLSAzLjIgaW4gdGhpcyBzcGVjaWZpYyBjYXNl Ljxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkkgdHJpZWQgdG89CiBzZXQgdGhlIGNvbmZp ZyB2YWx1ZSBmb3IgMy4yIGJ1dCBnb3Q6PGJyPjwvZGl2PjxkaXY+JCBlbmdpbmUtY29uZmlnIC1z IEN1cz0KdG9tRGV2aWNlUHJvcGVydGllcz0zRCJ7dHlwZT0zRGludGVyZmFjZTtwcm9wPTNEe215 UHJvcD0zRFthLXpBLVowLTktXSt9fSIgPQotLWN2ZXI9M0QzLjI8YnI+Q2Fubm90IHNldCB2YWx1 ZSB7dHlwZT0zRGludGVyZmFjZTtwcm9wPTNEe215UHJvcD0zRFthLXpBLVo9CjAtOS1dK319IHRv IGtleSBDdXN0b21EZXZpY2VQcm9wZXJ0aWVzLiBEZXZpY2UgY3VzdG9tIHByb3BlcnRpZXMgYXJl IG5vdCBzdT0KcHBvcnRlZCBpbiB2ZXJzaW9uIDMuMjxicj48YnI+PC9kaXY+PGRpdj5UaGlzIGlz IGFscmVhZHkgbm90IHZlcnkgZ29vZCwgc2luPQpjZSBpbiBhIDMuMiBEQyB0aGVyZSBjYW4gYmUg My4zIGNsdXN0ZXJzIHdpdGggMy4zIGhvc3RzIHRoYXQgZG8gc3VwcG9ydCBjdXM9CnRvbSBkZXZp Y2UgcHJvcGVydGllcy48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JIGFsc28gdHJpZWQg dG8gYWx0ZXIgdD0KaGUgY29uZmlnIHZhbHVlIGluIHRoZSBEQiBkaXJlY3RseSwgYnV0IHRoZSBj dXN0b20gcHJvcGVydGllcyBjb2RlIGlnbm9yZWQgPQppdCBzaW5jZSBjdXN0b20gcHJvcGVydGll cyBhcmUgbm90IHN1cHBvcnRlZCBpbiAzLjIuPGJyPjwvZGl2PjxkaXY+U28sIGRlIGY9CmFjdG8s IEkgaGF2ZSBubyByZWFzb25hYmxlIHdheSBhcyBhIHVzZXIgdG8gZGVmaW5lIGN1c3RvbSBkZXZp Y2UgcHJvcGVydGllcz0KIHRvIHVzZSBmb3IgbXkgdk5JQyBwcm9maWxlcyBpbiBEQyAmbHQ7IDMu My48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JPQogb3BlbmVkIHRoZSBidWcgPGEgaHJl Zj0zRCJodHRwczovL2J1Z3ppbGxhLnJlZGhhdC5jb20vc2hvd19idWcuY2dpP2lkPTNEMTA9CjI4 NzU3Ij5odHRwczovL2J1Z3ppbGxhLnJlZGhhdC5jb20vc2hvd19idWcuY2dpP2lkPTNEMTAyODc1 NzwvYT4gZm9yIHRoaXMsID0KaG93ZXZlciBJIGFsc28gd2FudCB0byBkaXNjdXNzIHRoZSBzaXR1 YXRpb246PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4xLiBBPQpzIGEgdXNlciwgSSBjYW4ndCBz ZXQgY3VzdG9tIHByb3BlcnRpZXMgZm9yIGxldmVsICZsdDsgMy4zIHdoaWNoIGlzIG5vdCBnb289 CmQuPGJyPjwvZGl2PjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlbW92aW5nIHRoZSBibG9ja2lu ZywgYW5kIGxvYWRpbmcgY3VzdD0Kb20gcHJvcGVydGllcyBmb3IgYWxsIHZlcnNpb25zIHdvdWxk IGZpeCB0aGUgYnVnIGFuZCBhbGxvdyB1c2luZyBjdXN0b20gZGV2PQppY2UgcHJvcGVydGllcyBm b3Igb2xkZXIgdmVyc2lvbnMsIHRoZSByZWFzb25hYmxlIHBsYWNlIHRvIGJsb2NrIHRoaXMgd291 bGQ9CiBiZSBydW5uaW5nIGEgVk0gKG9yIHBsdWdnaW5nIGEgZGV2aWNlKS48YnI+PC9kaXY+PGRp dj4mbmJzcDsmbmJzcDsmbmJzcDsgQj0KYXNpY2FsbHkgdGhpcyBpcyB0aGUgbGVzc2VyIGlzc3Vl Li48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4yLiBJIGp1c3QgPQpkb24ndCBzZWUgdGhl IGFkZGVkIHZhbHVlIG9mIHNwbGl0dGluZyB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgcHJvcGVydGll cyBwZXI9CiBsZXZlbC4uPGJyPjwvZGl2PjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBjdXN0 b20gcHJvcGVydGllcyBhcmUgZXh0ZW5zaT0Kb25zIHdoaWNoIG1pZ2h0IG9yIG1pZ2h0IG5vdCBi ZSBhdmFpbGFibGUgdG8gYSBjZXJ0YWluIFZNLCBJIGRvbid0IHNlZSBob3cgPQpoYXZpbmcgZGlm ZmVyZW50IHNldHMgb2YgY3VzdG9tIHByb3BlcnRpZXMgcGVyIHZlcnNpb24gKHdoYXQgdmVyc2lv biwgREMgdmU9CnJzaW9uLCBjbHVzdGVyIHZlcnNpb24/KSB3b3VsZCBtYWtlIGFueSBkaWZmZXJl bmNlIC0gZWl0aGVyIHRoZSBWTSBjYW4gdXRpbD0KaXplIHRoZSBleHRlbnNpb24gZ2l2ZW4gc29t ZSBzdGF0ZSBvZiB0aGUgc3lzdGVtLCBvciBpdCBjYW4ndCwgYnV0IHRoZSBkZXRlPQpybWluaW5n IGZhY3RvciBpcyBub3QgdGhlIHZlcnNpb24gYnV0IHJhdGhlciB0aGUgYXZhaWxhYmlsaXR5IG9m IHRoZSBleHRlbnM9Cmlvbi48YnI+PC9kaXY+PGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgRm9yIGV4 YW1wbGUsIEkgY2FuIGhhdmUgYSBob29rIGZvciB2Tj0KSUMgYWx0ZXJpbmcgc29tZSBwcm9wZXJ0 eSBpbnN0YWxsZWQgb24gaG9zdCBBIGFuZCBub3QgaG9zdCBCLCBpZiB0aGUgVk0gcnVuPQpzIG9u IGhvc3QgQSBpdCB3aWxsIGdldCB0aGlzIGNhcGFiaWxpdHkgYW5kIG9uIGhvc3QgQiBpdCB3b24n dCwgcmVnYXJkbGVzcyA9CnRoZSBEQyB2ZXJzaW9uIHRoZSBWTSBpcyBpbi48YnI+PC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj4mbmJzcDsmbmJzcDsmbmJzcD0KOyBUaGlzIGlzIG5vdCB0byBzYXkg d2Ugc2hvdWxkbid0IGJsb2NrIGN1c3RvbSBwcm9wZXJ0aWVzIG9uIHRoZSBlbmdpbmUtVkRTPQpN IEFQSSBsZXZlbCBzaW5jZSBpdCdzIG9ubHkgYXZhaWxhYmxlIHNpbmNlIDMuMywgYnV0IHRoaXMg aXMgaGFuZGxlZCBieSBhbm89CnRoZXIgY29uZmlnIHZhbHVlIChTdXBwb3J0Q3VzdG9tRGV2aWNl UHJvcGVydGllcykgd2hpY2ggaXMgbm90IGFsdGVyYWJsZSBieT0KIHRoZSB1c2VyLjxicj48L2Rp dj48ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBTbyBiYXNpY2FsbHksIEkgdGhpbmsgc3BsaXR0aW5n PQogdGhlIHZhbHVlIHBlciB2ZXJzaW9uIGlzIG92ZXIgY29tcGxpY2F0aW9uIGFuZCBzZWUgbm8g YWRkZWQgdmFsdWUgdG8gdGhlIHU9CnNlcnMsIGp1c3QgbW9yZSBtYWludGVuYW5jZSBzaG91bGQg dGhleSBjaG9vc2UgdG8gdXNlIHRoaXMgZmVhdHVyZS48YnI+PC9kaT0Kdj48ZGl2Pjxicj48L2Rp dj48ZGl2PllvdXIgdGhvdWdodHMgcGxlYXNlLjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 PjxzPQpwYW4gbmFtZT0zRCJ4Ij48L3NwYW4+UmVnYXJkcyw8YnI+TWlrZTxzcGFuIG5hbWU9M0Qi eCI+PC9zcGFuPjxicj48L2Rpdj48ZGk9CnY+PGJyPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ Ci0tLS0tLT1fUGFydF8yOTEyMTQzNF8xMjM4NTkzMzkyLjEzODQxNTYxNzM5MTQtLQo= --===============5282216648594801436==--