9:15 p.m.
This is a multi-part message in MIME format.
------=_NextPart_548A5DC3_0994A1A0_45B438FA
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: base64
RGVhciBhbGwsDQoNCkknbSBhY3R1YWxseSB3b3JraW5nIHRvIGNyZWF0ZSBhIGN1c3RvbSB1
c2VyIGludGVyZmFjZSBwbHVnaW4gZm9yIG9WaXJ0IHdlYiBhZG1pbmlzdHJhdGlvbiBhcHBs
aWNhdGlvbiB0byBsZXQgdXNlciB1cGxvYWQgaXNvIGZpbGVzLg0KDQpJJ20gaW4gdGhlIHZl
cnkgZmlyc3Qgc3RhZ2Ugb2YgdGhlIHByb2plY3QuIEknbSBwbGFubmluZyB0byB1c2UgYW5n
dWxhcmpzIHdpdGggdGhlIG5nLWZsb3cgbW9kdWxlIG9uIHRoZSBjbGllbnQtc2lkZSBhbmQg
YSBqYXZhIHNlcnZsZXQgdXNpbmcgdGhlIG92aXJ0LWlzby11cGxvYWRlciBlbmdpbmUgdG9v
bCBvbiB0aGUgc2VydmVyLXNpZGUuDQoNCkFsbCBteSBjb2RlIGlzIGdvaW5nIHRvIGJlIG9u
IEdpdGh1YiBpbiB0aGUgZm9sbG93aW5nIHJlcG9zaXRvcnkgOiBpc28tdXBsb2FkZXItcGx1
Z2luLiBZb3UgY2FuIGFsc28gY2hlY2sgYSBtb3JlIGRldGFpbGVkIHZlcnNpb24gb2YgdGhl
IHNwZWNpZmljYXRpb25zIG9uIG15IHdpa2kuDQoNCkknbSB3cml0aW5nIHRvIHlvdSBndXlz
IHRvIGtub3cgaWYgdGhlcmUgaXMgYSB3YXkgZm9yIHVzIHRvIGNvbGxhYm9yYXRlIGFzIHlv
dSBtYXkgYWxzbyB3YW50IHRvIGRldmVsb3Agc29tZXRoaW5nIGxpa2UgdGhpcyB0byBiZSBp
bnRlZ3JhdGVkIGluIHRoZSBvVmlydCBFbmdpbmUuDQoNCkJlc3QgcmVnYXJkcywNCg0KLSBM
dWNhcyBWYW5kcm91eCDvvIjlhq/lh6/vvIk=
------=_NextPart_548A5DC3_0994A1A0_45B438FA
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: base64
PGRpdj48cCBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgbWFyZ2luOiAwcHggMHB4
IDFyZW07IGNvbG9yOiByZ2IoODUsIDg0LCA4OSk7IGZvbnQtZmFtaWx5OiBMYXRvLCBzYW5z
LXNlcmlmOyBmb250LXNpemU6IDE4cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+RGVhciBhbGws
PC9wPjxwIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBtYXJnaW46IDBweCAwcHgg
MXJlbTsgY29sb3I6IHJnYig4NSwgODQsIDg5KTsgZm9udC1mYW1pbHk6IExhdG8sIHNhbnMt
c2VyaWY7IGZvbnQtc2l6ZTogMThweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5JJ20gYWN0dWFs
bHkgd29ya2luZyB0byBjcmVhdGUgYSBjdXN0b20gdXNlciBpbnRlcmZhY2UgcGx1Z2luIGZv
ciBvVmlydCB3ZWIgYWRtaW5pc3RyYXRpb24gYXBwbGljYXRpb24gdG8gbGV0IHVzZXIgdXBs
b2FkIGlzbyBmaWxlcy48L3A+PHAgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IG1h
cmdpbjogMHB4IDBweCAxcmVtOyBjb2xvcjogcmdiKDg1LCA4NCwgODkpOyBmb250LWZhbWls
eTogTGF0bywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxOHB4OyBsaW5lLWhlaWdodDogMjRw
eDsiPkknbSBpbiB0aGUgdmVyeSBmaXJzdCBzdGFnZSBvZiB0aGUgcHJvamVjdC4gSSdtIHBs
YW5uaW5nIHRvIHVzZSBhbmd1bGFyanMgd2l0aCB0aGUmbmJzcDs8YSBocmVmPSJodHRwczov
L2dpdGh1Yi5jb20vZmxvd2pzL25nLWZsb3ciIGRhdGEtcmVmZXJlci1zYWZlPSIxIiByZWw9
Im5vcmVmZXJyZXIiIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBjb2xvcjogcmdi
KDY3LCAxNTksIDIyNCk7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPm5nLWZsb3cgbW9kdWxl
PC9hPiZuYnNwO29uIHRoZSBjbGllbnQtc2lkZSBhbmQgYSBqYXZhIHNlcnZsZXQgdXNpbmcg
dGhlJm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy5vdmlydC5vcmcvT1ZpcnRfZW5naW5lX3Rv
b2xzI292aXJ0LWlzby11cGxvYWRlciIgZGF0YS1yZWZlcmVyLXNhZmU9IjEiIHJlbD0ibm9y
ZWZlcnJlciIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IGNvbG9yOiByZ2IoNjcs
IDE1OSwgMjI0KTsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+b3ZpcnQtaXNvLXVwbG9hZGVy
PC9hPiZuYnNwO2VuZ2luZSB0b29sIG9uIHRoZSBzZXJ2ZXItc2lkZS48L3A+PHAgc3R5bGU9
ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IG1hcmdpbjogMHB4IDBweCAxcmVtOyBjb2xvcjog
cmdiKDg1LCA4NCwgODkpOyBmb250LWZhbWlseTogTGF0bywgc2Fucy1zZXJpZjsgZm9udC1z
aXplOiAxOHB4OyBsaW5lLWhlaWdodDogMjRweDsiPkFsbCBteSBjb2RlIGlzIGdvaW5nIHRv
IGJlIG9uIEdpdGh1YiBpbiB0aGUgZm9sbG93aW5nIHJlcG9zaXRvcnkgOiZuYnNwOzxhIGhy
ZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9vdmlydC1jaGluYS9pc28tdXBsb2FkZXItcGx1Z2lu
IiBkYXRhLXJlZmVyZXItc2FmZT0iMSIgcmVsPSJub3JlZmVycmVyIiBzdHlsZT0iYm94LXNp
emluZzogYm9yZGVyLWJveDsgY29sb3I6IHJnYig2NywgMTU5LCAyMjQpOyB0ZXh0LWRlY29y
YXRpb246IG5vbmU7Ij5pc28tdXBsb2FkZXItcGx1Z2luPC9hPi4gWW91IGNhbiBhbHNvIGNo
ZWNrIGEgbW9yZSBkZXRhaWxlZCB2ZXJzaW9uIG9mIHRoZSZuYnNwOzxhIGhyZWY9Imh0dHBz
Oi8vZ2l0aHViLmNvbS9vdmlydC1jaGluYS9pc28tdXBsb2FkZXItcGx1Z2luL3dpa2kvU3Bl
Y2lmaWNhdGlvbnMiIGRhdGEtcmVmZXJlci1zYWZlPSIxIiByZWw9Im5vcmVmZXJyZXIiIHN0
eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBjb2xvcjogcmdiKDY3LCAxNTksIDIyNCk7
IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPnNwZWNpZmljYXRpb25zIG9uIG15IHdpa2k8L2E+
LjwvcD48cCBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgbWFyZ2luOiAwcHggMHB4
IDFyZW07IGNvbG9yOiByZ2IoODUsIDg0LCA4OSk7IGZvbnQtZmFtaWx5OiBMYXRvLCBzYW5z
LXNlcmlmOyBmb250LXNpemU6IDE4cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+SSdtIHdyaXRp
bmcgdG8geW91IGd1eXMgdG8ga25vdyBpZiB0aGVyZSBpcyBhIHdheSBmb3IgdXMgdG8gY29s
bGFib3JhdGUgYXMgeW91IG1heSBhbHNvIHdhbnQgdG8gZGV2ZWxvcCBzb21ldGhpbmcgbGlr
ZSB0aGlzIHRvIGJlIGludGVncmF0ZWQgaW4gdGhlIG9WaXJ0IEVuZ2luZS48L3A+PHAgc3R5
bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IG1hcmdpbjogMHB4IDBweCAxcmVtOyBjb2xv
cjogcmdiKDg1LCA4NCwgODkpOyBmb250LWZhbWlseTogTGF0bywgc2Fucy1zZXJpZjsgZm9u
dC1zaXplOiAxOHB4OyBsaW5lLWhlaWdodDogMjRweDsiPkJlc3QgcmVnYXJkcyw8L3A+PHAg
c3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IG1hcmdpbjogMHB4IDBweCAxcmVtOyBj
b2xvcjogcmdiKDg1LCA4NCwgODkpOyBmb250LWZhbWlseTogTGF0bywgc2Fucy1zZXJpZjsg
Zm9udC1zaXplOiAxOHB4OyI+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyNHB4OyI+LSZu
YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDEuNTsiPkx1Y2FzIFZhbmRy
b3V4IO+8iOWGr+WHr++8iTwvc3Bhbj48L3A+PC9kaXY+PGRpdj48aW5jbHVkZXRhaWw+PCEt
LTwhW2VuZGlmXS0tPjwvaW5jbHVkZXRhaWw+PC9kaXY+
------=_NextPart_548A5DC3_0994A1A0_45B438FA--
3:35 p.m.
On 12/12/2014 05:15 AM, Lucas Vandroux wrote:
Dear all,
I'm actually working to create a custom user interface plugin for oVirt
web administration application to let user upload iso files.
I'm in the very first stage of the project. I'm planning to use
angularjs with the ng-flow module <https://github.com/flowjs/ng-flow> on
the client-side and a java servlet using the ovirt-iso-uploader
<http://www.ovirt.org/OVirt_engine_tools#ovirt-iso-uploader> engine tool
on the server-side.
All my code is going to be on Github in the following repository :
iso-uploader-plugin
<https://github.com/ovirt-china/iso-uploader-plugin>;. You can also check
a more detailed version of the specifications on my wiki
<https://github.com/ovirt-china/iso-uploader-plugin/wiki/Specifications>;.
I'm writing to you guys to know if there is a way for us to collaborate
as you may also want to develop something like this to be integrated in
the oVirt Engine.
Best regards,
- Lucas Vandroux （冯凯）
looks very nice.
This is actually very interesting (and requested by multiple folks) but
i'd like to see if we should focus on the more simple "upload iso's" or
it doing more than just upload ISO's, but also VMs.
for the latter, architecture would probably be a servlet[1] on the
engine and stream to vdsm to write to storage, so both vm disks and/or
iso's could be uploaded/downloaded.
one thing to consider with above architecture is need to handle
ticketing between servlet to validate end user is allowed to do this,
and for more advanced - some throttling.
another concern is choice of technologies to see if can be properly
packaged to be provided as more than just an optional ui plugin.
a question - i couldn't easily locate a screenshot/explanation how your
plugin dialog for upload looks like / how you handle authentication in
it now?
thanks,
Itamar
[1] servlet to can be moved to another host and to not hog engine
backend itself.
3:47 p.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Lucas Vandroux" <lucas.vandroux(a)eayun.com>, "devel"
<devel(a)ovirt.org>, "潘礼洋" <liyang.pan(a)eayun.com>, "李建盛"
<jiansheng.li(a)eayun.com>
Cc: "Michal Skrivanek" <mskrivan(a)redhat.com>, "Scott Herold"
<sherold(a)redhat.com>, "Allon Mureinik"
<amureini(a)redhat.com>, "Federico Simoncelli" <fsimonce(a)redhat.com>,
"Barak Azulay" <bazulay(a)redhat.com>, "Brian
Proffitt" <bproffit(a)redhat.com>, "Alon Bar-Lev"
<alonbl(a)redhat.com>
Sent: Sunday, December 14, 2014 11:35:40 PM
Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
On 12/12/2014 05:15 AM, Lucas Vandroux wrote:
> Dear all,
>
> I'm actually working to create a custom user interface plugin for oVirt
> web administration application to let user upload iso files.
>
> I'm in the very first stage of the project. I'm planning to use
> angularjs with the ng-flow module <https://github.com/flowjs/ng-flow> on
> the client-side and a java servlet using the ovirt-iso-uploader
> <http://www.ovirt.org/OVirt_engine_tools#ovirt-iso-uploader> engine tool
> on the server-side.
>
> All my code is going to be on Github in the following repository :
> iso-uploader-plugin
> <https://github.com/ovirt-china/iso-uploader-plugin>;. You can also check
> a more detailed version of the specifications on my wiki
> <https://github.com/ovirt-china/iso-uploader-plugin/wiki/Specifications>;.
>
> I'm writing to you guys to know if there is a way for us to collaborate
> as you may also want to develop something like this to be integrated in
> the oVirt Engine.
>
> Best regards,
>
> - Lucas Vandroux （冯凯）
>
>
looks very nice.
This is actually very interesting (and requested by multiple folks) but
i'd like to see if we should focus on the more simple "upload iso's"
or
it doing more than just upload ISO's, but also VMs.
for the latter, architecture would probably be a servlet[1] on the
engine and stream to vdsm to write to storage, so both vm disks and/or
iso's could be uploaded/downloaded.
using ssh and/or nfs to send artifacts to hosts is something we should avoid so using
iso/image uploader tools are not a solution.
vdsm should support uploading images using its own protocol based on the authentication
between engine and vdsm, is it already?
this should be a core feature not an add-on within the current monolithic implementation,
as there is no access to vdsm interaction from any of the interfaces.
Alon
9:50 a.m.
On Dec 14, 2014, at 22:47 , Alon Bar-Lev <alonbl(a)redhat.com> wrote:
----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Lucas Vandroux" <lucas.vandroux(a)eayun.com>, "devel"
<devel(a)ovirt.org>, "潘礼洋" <liyang.pan(a)eayun.com>, "李建盛"
> <jiansheng.li(a)eayun.com>
> Cc: "Michal Skrivanek" <mskrivan(a)redhat.com>, "Scott
Herold" <sherold(a)redhat.com>, "Allon Mureinik"
> <amureini(a)redhat.com>, "Federico Simoncelli"
<fsimonce(a)redhat.com>, "Barak Azulay" <bazulay(a)redhat.com>,
"Brian
> Proffitt" <bproffit(a)redhat.com>, "Alon Bar-Lev"
<alonbl(a)redhat.com>
> Sent: Sunday, December 14, 2014 11:35:40 PM
> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>
> On 12/12/2014 05:15 AM, Lucas Vandroux wrote:
>> Dear all,
>>
>> I'm actually working to create a custom user interface plugin for oVirt
>> web administration application to let user upload iso files.
>>
>> I'm in the very first stage of the project. I'm planning to use
>> angularjs with the ng-flow module <https://github.com/flowjs/ng-flow> on
>> the client-side and a java servlet using the ovirt-iso-uploader
>> <http://www.ovirt.org/OVirt_engine_tools#ovirt-iso-uploader> engine tool
>> on the server-side.
>>
>> All my code is going to be on Github in the following repository :
>> iso-uploader-plugin
>> <https://github.com/ovirt-china/iso-uploader-plugin>;. You can also check
>> a more detailed version of the specifications on my wiki
>> <https://github.com/ovirt-china/iso-uploader-plugin/wiki/Specifications>;.
>>
>> I'm writing to you guys to know if there is a way for us to collaborate
>> as you may also want to develop something like this to be integrated in
>> the oVirt Engine.
>>
>> Best regards,
>>
>> - Lucas Vandroux （冯凯）
>>
>>
>
> looks very nice.
>
> This is actually very interesting (and requested by multiple folks) but
> i'd like to see if we should focus on the more simple "upload
iso's" or
> it doing more than just upload ISO's, but also VMs.
> for the latter, architecture would probably be a servlet[1] on the
> engine and stream to vdsm to write to storage, so both vm disks and/or
> iso's could be uploaded/downloaded.
using ssh and/or nfs to send artifacts to hosts is something we should avoid so using
iso/image uploader tools are not a solution.
vdsm should support uploading images using its own protocol based on the authentication
between engine and vdsm, is it already?
nope, we don't
this should be a core feature not an add-on within the current
monolithic implementation, as there is no access to vdsm interaction from any of the
interfaces.
well, since we have this feature in the plan for a long time and didn't get to it then
a UI plugin would be nice.
Currently the only way to upload "stuff" is using ovirt-iso-uploader.
Thanks,
michal
Alon
10:47 a.m.
----- Original Message -----
From: "Alon Bar-Lev" <alonbl(a)redhat.com>
To: "Itamar Heim" <iheim(a)redhat.com>
Cc: "devel" <devel(a)ovirt.org>, "Lucas Vandroux"
<lucas.vandroux(a)eayun.com>, "李建盛" <jiansheng.li(a)eayun.com>,
"潘礼洋"
<liyang.pan(a)eayun.com>, "Michal Skrivanek" <mskrivan(a)redhat.com>
Sent: Sunday, December 14, 2014 11:47:26 PM
Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Lucas Vandroux" <lucas.vandroux(a)eayun.com>, "devel"
<devel(a)ovirt.org>,
> "潘礼洋" <liyang.pan(a)eayun.com>, "李建盛"
> <jiansheng.li(a)eayun.com>
> Cc: "Michal Skrivanek" <mskrivan(a)redhat.com>, "Scott
Herold"
> <sherold(a)redhat.com>, "Allon Mureinik"
> <amureini(a)redhat.com>, "Federico Simoncelli"
<fsimonce(a)redhat.com>, "Barak
> Azulay" <bazulay(a)redhat.com>, "Brian
> Proffitt" <bproffit(a)redhat.com>, "Alon Bar-Lev"
<alonbl(a)redhat.com>
> Sent: Sunday, December 14, 2014 11:35:40 PM
> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>
> On 12/12/2014 05:15 AM, Lucas Vandroux wrote:
> > Dear all,
> >
> > I'm actually working to create a custom user interface plugin for oVirt
> > web administration application to let user upload iso files.
> >
> > I'm in the very first stage of the project. I'm planning to use
> > angularjs with the ng-flow module <https://github.com/flowjs/ng-flow> on
> > the client-side and a java servlet using the ovirt-iso-uploader
> > <http://www.ovirt.org/OVirt_engine_tools#ovirt-iso-uploader> engine tool
> > on the server-side.
> >
> > All my code is going to be on Github in the following repository :
> > iso-uploader-plugin
> > <https://github.com/ovirt-china/iso-uploader-plugin>;. You can also check
> > a more detailed version of the specifications on my wiki
> >
<https://github.com/ovirt-china/iso-uploader-plugin/wiki/Specifications>;.
> >
> > I'm writing to you guys to know if there is a way for us to collaborate
> > as you may also want to develop something like this to be integrated in
> > the oVirt Engine.
> >
> > Best regards,
> >
> > - Lucas Vandroux （冯凯）
> >
> >
>
> looks very nice.
>
> This is actually very interesting (and requested by multiple folks) but
> i'd like to see if we should focus on the more simple "upload
iso's" or
> it doing more than just upload ISO's, but also VMs.
> for the latter, architecture would probably be a servlet[1] on the
> engine and stream to vdsm to write to storage, so both vm disks and/or
> iso's could be uploaded/downloaded.
using ssh and/or nfs to send artifacts to hosts is something we should avoid
so using iso/image uploader tools are not a solution.
vdsm should support uploading images using its own protocol based on the
authentication between engine and vdsm, is it already?
Vdsm does support upload over http/https directly to storage.
This feature is used to store ovf backups on storage domains, and probably
not very efficient, but may be good enough for now.
See vdsm/rpc/BindingXMLRPC.py (do_PUT)
this should be a core feature not an add-on within the current
monolithic
implementation, as there is no access to vdsm interaction from any of the
interfaces.
Nir
10:52 a.m.
----- Original Message -----
From: "Nir Soffer" <nsoffer(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: "Itamar Heim" <iheim(a)redhat.com>, "devel"
<devel(a)ovirt.org>, "Lucas Vandroux" <lucas.vandroux(a)eayun.com>,
"李建盛"
<jiansheng.li(a)eayun.com>, "潘礼洋" <liyang.pan(a)eayun.com>,
"Michal Skrivanek" <mskrivan(a)redhat.com>, "Liron Aravot"
<laravot(a)redhat.com>
Sent: Monday, December 15, 2014 6:47:44 PM
Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
----- Original Message -----
> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> To: "Itamar Heim" <iheim(a)redhat.com>
> Cc: "devel" <devel(a)ovirt.org>, "Lucas Vandroux"
<lucas.vandroux(a)eayun.com>,
> "李建盛" <jiansheng.li(a)eayun.com>, "潘礼洋"
> <liyang.pan(a)eayun.com>, "Michal Skrivanek"
<mskrivan(a)redhat.com>
> Sent: Sunday, December 14, 2014 11:47:26 PM
> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>
>
>
> ----- Original Message -----
> > From: "Itamar Heim" <iheim(a)redhat.com>
> > To: "Lucas Vandroux" <lucas.vandroux(a)eayun.com>,
"devel"
> > <devel(a)ovirt.org>,
> > "潘礼洋" <liyang.pan(a)eayun.com>, "李建盛"
> > <jiansheng.li(a)eayun.com>
> > Cc: "Michal Skrivanek" <mskrivan(a)redhat.com>, "Scott
Herold"
> > <sherold(a)redhat.com>, "Allon Mureinik"
> > <amureini(a)redhat.com>, "Federico Simoncelli"
<fsimonce(a)redhat.com>,
> > "Barak
> > Azulay" <bazulay(a)redhat.com>, "Brian
> > Proffitt" <bproffit(a)redhat.com>, "Alon Bar-Lev"
<alonbl(a)redhat.com>
> > Sent: Sunday, December 14, 2014 11:35:40 PM
> > Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
> >
> > On 12/12/2014 05:15 AM, Lucas Vandroux wrote:
> > > Dear all,
> > >
> > > I'm actually working to create a custom user interface plugin for
oVirt
> > > web administration application to let user upload iso files.
> > >
> > > I'm in the very first stage of the project. I'm planning to use
> > > angularjs with the ng-flow module
<https://github.com/flowjs/ng-flow>
> > > on
> > > the client-side and a java servlet using the ovirt-iso-uploader
> > > <http://www.ovirt.org/OVirt_engine_tools#ovirt-iso-uploader> engine
> > > tool
> > > on the server-side.
> > >
> > > All my code is going to be on Github in the following repository :
> > > iso-uploader-plugin
> > > <https://github.com/ovirt-china/iso-uploader-plugin>;. You can also
> > > check
> > > a more detailed version of the specifications on my wiki
> > >
<https://github.com/ovirt-china/iso-uploader-plugin/wiki/Specifications>;.
> > >
> > > I'm writing to you guys to know if there is a way for us to
collaborate
> > > as you may also want to develop something like this to be integrated in
> > > the oVirt Engine.
> > >
> > > Best regards,
> > >
> > > - Lucas Vandroux （冯凯）
> > >
> > >
> >
> > looks very nice.
> >
> > This is actually very interesting (and requested by multiple folks) but
> > i'd like to see if we should focus on the more simple "upload
iso's" or
> > it doing more than just upload ISO's, but also VMs.
> > for the latter, architecture would probably be a servlet[1] on the
> > engine and stream to vdsm to write to storage, so both vm disks and/or
> > iso's could be uploaded/downloaded.
>
> using ssh and/or nfs to send artifacts to hosts is something we should
> avoid
> so using iso/image uploader tools are not a solution.
> vdsm should support uploading images using its own protocol based on the
> authentication between engine and vdsm, is it already?
Vdsm does support upload over http/https directly to storage.
This feature is used to store ovf backups on storage domains, and probably
not very efficient, but may be good enough for now.
See vdsm/rpc/BindingXMLRPC.py (do_PUT)
thanks.
I hear this function is not supported by the new jsonrpc, nor will it be supported when
messaging will be used... so not sure if it is a good idea to add functionality on top of
this one.
this should be core feature, it cannot be implemented as plugin within the current
monolithic implementation.
> this should be a core feature not an add-on within the current monolithic
> implementation, as there is no access to vdsm interaction from any of the
> interfaces.
Nir
10:54 a.m.
----- Original Message -----
From: "Michal Skrivanek" <mskrivan(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: "Itamar Heim" <iheim(a)redhat.com>, "Lucas Vandroux"
<lucas.vandroux(a)eayun.com>, "devel" <devel(a)ovirt.org>,
"潘礼洋"
<liyang.pan(a)eayun.com>, "李建盛" <jiansheng.li(a)eayun.com>, "Scott
Herold" <sherold(a)redhat.com>, "Allon Mureinik"
<amureini(a)redhat.com>, "Federico Simoncelli" <fsimonce(a)redhat.com>,
"Barak Azulay" <bazulay(a)redhat.com>, "Brian
Proffitt" <bproffit(a)redhat.com>
Sent: Monday, December 15, 2014 5:50:21 PM
Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
On Dec 14, 2014, at 22:47 , Alon Bar-Lev <alonbl(a)redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim(a)redhat.com>
>> To: "Lucas Vandroux" <lucas.vandroux(a)eayun.com>,
"devel"
>> <devel(a)ovirt.org>, "潘礼洋" <liyang.pan(a)eayun.com>,
"李建盛"
>> <jiansheng.li(a)eayun.com>
>> Cc: "Michal Skrivanek" <mskrivan(a)redhat.com>, "Scott
Herold"
>> <sherold(a)redhat.com>, "Allon Mureinik"
>> <amureini(a)redhat.com>, "Federico Simoncelli"
<fsimonce(a)redhat.com>, "Barak
>> Azulay" <bazulay(a)redhat.com>, "Brian
>> Proffitt" <bproffit(a)redhat.com>, "Alon Bar-Lev"
<alonbl(a)redhat.com>
>> Sent: Sunday, December 14, 2014 11:35:40 PM
>> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>>
>> On 12/12/2014 05:15 AM, Lucas Vandroux wrote:
>>> Dear all,
>>>
>>> I'm actually working to create a custom user interface plugin for oVirt
>>> web administration application to let user upload iso files.
>>>
>>> I'm in the very first stage of the project. I'm planning to use
>>> angularjs with the ng-flow module <https://github.com/flowjs/ng-flow>
on
>>> the client-side and a java servlet using the ovirt-iso-uploader
>>> <http://www.ovirt.org/OVirt_engine_tools#ovirt-iso-uploader> engine
tool
>>> on the server-side.
>>>
>>> All my code is going to be on Github in the following repository :
>>> iso-uploader-plugin
>>> <https://github.com/ovirt-china/iso-uploader-plugin>;. You can also
check
>>> a more detailed version of the specifications on my wiki
>>>
<https://github.com/ovirt-china/iso-uploader-plugin/wiki/Specifications>;.
>>>
>>> I'm writing to you guys to know if there is a way for us to collaborate
>>> as you may also want to develop something like this to be integrated in
>>> the oVirt Engine.
>>>
>>> Best regards,
>>>
>>> - Lucas Vandroux （冯凯）
>>>
>>>
>>
>> looks very nice.
>>
>> This is actually very interesting (and requested by multiple folks) but
>> i'd like to see if we should focus on the more simple "upload
iso's" or
>> it doing more than just upload ISO's, but also VMs.
>> for the latter, architecture would probably be a servlet[1] on the
>> engine and stream to vdsm to write to storage, so both vm disks and/or
>> iso's could be uploaded/downloaded.
>
> using ssh and/or nfs to send artifacts to hosts is something we should
> avoid so using iso/image uploader tools are not a solution.
> vdsm should support uploading images using its own protocol based on the
> authentication between engine and vdsm, is it already?
nope, we don't
> this should be a core feature not an add-on within the current monolithic
> implementation, as there is no access to vdsm interaction from any of the
> interfaces.
well, since we have this feature in the plan for a long time and didn't get
to it then a UI plugin would be nice.
Currently the only way to upload "stuff" is using ovirt-iso-uploader.
indeed "nice", but we cannot introduce anything that is "nice" but
insecure. using iso/image uplaoder spawned by servlet cannot be something that is
endorsed.
11:09 a.m.
----- Original Message -----
From: "Alon Bar-Lev" <alonbl(a)redhat.com>
To: "Nir Soffer" <nsoffer(a)redhat.com>
Cc: "devel" <devel(a)ovirt.org>, "李建盛"
<jiansheng.li(a)eayun.com>, "Lucas Vandroux"
<lucas.vandroux(a)eayun.com>, "Liron
Aravot" <laravot(a)redhat.com>, "潘礼洋" <liyang.pan(a)eayun.com>,
"Michal Skrivanek" <mskrivan(a)redhat.com>
Sent: Monday, December 15, 2014 5:52:36 PM
Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
----- Original Message -----
> From: "Nir Soffer" <nsoffer(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> Cc: "Itamar Heim" <iheim(a)redhat.com>, "devel"
<devel(a)ovirt.org>, "Lucas
> Vandroux" <lucas.vandroux(a)eayun.com>, "李建盛"
> <jiansheng.li(a)eayun.com>, "潘礼洋" <liyang.pan(a)eayun.com>,
"Michal Skrivanek"
> <mskrivan(a)redhat.com>, "Liron Aravot"
> <laravot(a)redhat.com>
> Sent: Monday, December 15, 2014 6:47:44 PM
> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > To: "Itamar Heim" <iheim(a)redhat.com>
> > Cc: "devel" <devel(a)ovirt.org>, "Lucas Vandroux"
> > <lucas.vandroux(a)eayun.com>,
> > "李建盛" <jiansheng.li(a)eayun.com>, "潘礼洋"
> > <liyang.pan(a)eayun.com>, "Michal Skrivanek"
<mskrivan(a)redhat.com>
> > Sent: Sunday, December 14, 2014 11:47:26 PM
> > Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
> >
> >
> > using ssh and/or nfs to send artifacts to hosts is something we should
> > avoid
> > so using iso/image uploader tools are not a solution.
> > vdsm should support uploading images using its own protocol based on the
> > authentication between engine and vdsm, is it already?
>
> Vdsm does support upload over http/https directly to storage.
>
> This feature is used to store ovf backups on storage domains, and probably
> not very efficient, but may be good enough for now.
>
> See vdsm/rpc/BindingXMLRPC.py (do_PUT)
thanks.
I hear this function is not supported by the new jsonrpc, nor will it be
supported when messaging will be used... so not sure if it is a good idea to
add functionality on top of this one.
The format (xmlrpc/jsonrpc) here is not much interesting, the interesting
part is the transport. In fact current download/uploadImage uses REST
GET/PUT for downloading/uploading the images (only the errors/messages are
reported with xmlrpc or eventually they could be reported with jsonrpc).
By design they were not mixed with the other control APIs (because it's
not control, it's data). And indeed it cannot be transported with
messaging.
Uploading/dowloading data to/from the host involves a data transport
(and http REST is the most commonly used). Which is exactly what you
need here, and it was in fact designed for this use case.
this should be core feature, it cannot be implemented as plugin
within the
current monolithic implementation.
+1
--
Federico
11:15 a.m.
----- Original Message -----
From: "Federico Simoncelli" <fsimonce(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: "Nir Soffer" <nsoffer(a)redhat.com>, "devel"
<devel(a)ovirt.org>, "李建盛" <jiansheng.li(a)eayun.com>, "Lucas
Vandroux"
<lucas.vandroux(a)eayun.com>, "Liron Aravot" <laravot(a)redhat.com>,
"潘礼洋" <liyang.pan(a)eayun.com>, "Michal Skrivanek"
<mskrivan(a)redhat.com>
Sent: Monday, December 15, 2014 7:09:11 PM
Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
----- Original Message -----
> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> To: "Nir Soffer" <nsoffer(a)redhat.com>
> Cc: "devel" <devel(a)ovirt.org>, "李建盛"
<jiansheng.li(a)eayun.com>, "Lucas
> Vandroux" <lucas.vandroux(a)eayun.com>, "Liron
> Aravot" <laravot(a)redhat.com>, "潘礼洋"
<liyang.pan(a)eayun.com>, "Michal
> Skrivanek" <mskrivan(a)redhat.com>
> Sent: Monday, December 15, 2014 5:52:36 PM
> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>
> ----- Original Message -----
> > From: "Nir Soffer" <nsoffer(a)redhat.com>
> > To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > Cc: "Itamar Heim" <iheim(a)redhat.com>, "devel"
<devel(a)ovirt.org>, "Lucas
> > Vandroux" <lucas.vandroux(a)eayun.com>, "李建盛"
> > <jiansheng.li(a)eayun.com>, "潘礼洋" <liyang.pan(a)eayun.com>,
"Michal
> > Skrivanek"
> > <mskrivan(a)redhat.com>, "Liron Aravot"
> > <laravot(a)redhat.com>
> > Sent: Monday, December 15, 2014 6:47:44 PM
> > Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
> >
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > To: "Itamar Heim" <iheim(a)redhat.com>
> > > Cc: "devel" <devel(a)ovirt.org>, "Lucas Vandroux"
> > > <lucas.vandroux(a)eayun.com>,
> > > "李建盛" <jiansheng.li(a)eayun.com>, "潘礼洋"
> > > <liyang.pan(a)eayun.com>, "Michal Skrivanek"
<mskrivan(a)redhat.com>
> > > Sent: Sunday, December 14, 2014 11:47:26 PM
> > > Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
> > >
> > >
> > > using ssh and/or nfs to send artifacts to hosts is something we should
> > > avoid
> > > so using iso/image uploader tools are not a solution.
> > > vdsm should support uploading images using its own protocol based on
> > > the
> > > authentication between engine and vdsm, is it already?
> >
> > Vdsm does support upload over http/https directly to storage.
> >
> > This feature is used to store ovf backups on storage domains, and
> > probably
> > not very efficient, but may be good enough for now.
> >
> > See vdsm/rpc/BindingXMLRPC.py (do_PUT)
>
> thanks.
> I hear this function is not supported by the new jsonrpc, nor will it be
> supported when messaging will be used... so not sure if it is a good idea
> to
> add functionality on top of this one.
The format (xmlrpc/jsonrpc) here is not much interesting, the interesting
part is the transport. In fact current download/uploadImage uses REST
GET/PUT for downloading/uploading the images (only the errors/messages are
reported with xmlrpc or eventually they could be reported with jsonrpc).
By design they were not mixed with the other control APIs (because it's
not control, it's data). And indeed it cannot be transported with
messaging.
Uploading/dowloading data to/from the host involves a data transport
(and http REST is the most commonly used). Which is exactly what you
need here, and it was in fact designed for this use case.
there are plans to use messaging/broker to access hosts.
this should abstract the physical location of the host.
using direct connection to host in addition to broker is something that should be
avoided.
once solution may be to obtain connection information from the control channel, but one of
the "problems" that will nice to be solved is to stop initiating connections
from manager.
> this should be core feature, it cannot be implemented as plugin within the
> current monolithic implementation.
+1
--
Federico
11:33 a.m.
----- Original Message -----
From: "Alon Bar-Lev" <alonbl(a)redhat.com>
To: "Federico Simoncelli" <fsimonce(a)redhat.com>
Cc: "Nir Soffer" <nsoffer(a)redhat.com>, "devel"
<devel(a)ovirt.org>, "李建盛" <jiansheng.li(a)eayun.com>, "Lucas
Vandroux"
<lucas.vandroux(a)eayun.com>, "Liron Aravot" <laravot(a)redhat.com>,
"潘礼洋" <liyang.pan(a)eayun.com>, "Michal Skrivanek"
<mskrivan(a)redhat.com>
Sent: Monday, December 15, 2014 6:15:53 PM
Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
----- Original Message -----
> From: "Federico Simoncelli" <fsimonce(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> Cc: "Nir Soffer" <nsoffer(a)redhat.com>, "devel"
<devel(a)ovirt.org>, "李建盛"
> <jiansheng.li(a)eayun.com>, "Lucas Vandroux"
> <lucas.vandroux(a)eayun.com>, "Liron Aravot"
<laravot(a)redhat.com>, "潘礼洋"
> <liyang.pan(a)eayun.com>, "Michal Skrivanek"
> <mskrivan(a)redhat.com>
> Sent: Monday, December 15, 2014 7:09:11 PM
> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > To: "Nir Soffer" <nsoffer(a)redhat.com>
> > Cc: "devel" <devel(a)ovirt.org>, "李建盛"
<jiansheng.li(a)eayun.com>, "Lucas
> > Vandroux" <lucas.vandroux(a)eayun.com>, "Liron
> > Aravot" <laravot(a)redhat.com>, "潘礼洋"
<liyang.pan(a)eayun.com>, "Michal
> > Skrivanek" <mskrivan(a)redhat.com>
> > Sent: Monday, December 15, 2014 5:52:36 PM
> > Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
> >
> > ----- Original Message -----
> > > From: "Nir Soffer" <nsoffer(a)redhat.com>
> > > To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > Cc: "Itamar Heim" <iheim(a)redhat.com>, "devel"
<devel(a)ovirt.org>, "Lucas
> > > Vandroux" <lucas.vandroux(a)eayun.com>, "李建盛"
> > > <jiansheng.li(a)eayun.com>, "潘礼洋"
<liyang.pan(a)eayun.com>, "Michal
> > > Skrivanek"
> > > <mskrivan(a)redhat.com>, "Liron Aravot"
> > > <laravot(a)redhat.com>
> > > Sent: Monday, December 15, 2014 6:47:44 PM
> > > Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
> > >
> > > ----- Original Message -----
> > > > From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > > To: "Itamar Heim" <iheim(a)redhat.com>
> > > > Cc: "devel" <devel(a)ovirt.org>, "Lucas
Vandroux"
> > > > <lucas.vandroux(a)eayun.com>,
> > > > "李建盛" <jiansheng.li(a)eayun.com>, "潘礼洋"
> > > > <liyang.pan(a)eayun.com>, "Michal Skrivanek"
<mskrivan(a)redhat.com>
> > > > Sent: Sunday, December 14, 2014 11:47:26 PM
> > > > Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
> > > >
> > > >
> > > > using ssh and/or nfs to send artifacts to hosts is something we
> > > > should
> > > > avoid
> > > > so using iso/image uploader tools are not a solution.
> > > > vdsm should support uploading images using its own protocol based on
> > > > the
> > > > authentication between engine and vdsm, is it already?
> > >
> > > Vdsm does support upload over http/https directly to storage.
> > >
> > > This feature is used to store ovf backups on storage domains, and
> > > probably
> > > not very efficient, but may be good enough for now.
> > >
> > > See vdsm/rpc/BindingXMLRPC.py (do_PUT)
> >
> > thanks.
> > I hear this function is not supported by the new jsonrpc, nor will it be
> > supported when messaging will be used... so not sure if it is a good idea
> > to
> > add functionality on top of this one.
>
> The format (xmlrpc/jsonrpc) here is not much interesting, the interesting
> part is the transport. In fact current download/uploadImage uses REST
> GET/PUT for downloading/uploading the images (only the errors/messages are
> reported with xmlrpc or eventually they could be reported with jsonrpc).
>
> By design they were not mixed with the other control APIs (because it's
> not control, it's data). And indeed it cannot be transported with
> messaging.
>
> Uploading/dowloading data to/from the host involves a data transport
> (and http REST is the most commonly used). Which is exactly what you
> need here, and it was in fact designed for this use case.
there are plans to use messaging/broker to access hosts.
this should abstract the physical location of the host.
using direct connection to host in addition to broker is something that
should be avoided.
Agreed, although when we discussed how to coherently move large data
from/to the hosts it became obvious that messaging/broker is not the
right tool.
once solution may be to obtain connection information from the
control
channel, but one of the "problems" that will nice to be solved is to stop
initiating connections from manager.
Retrieving/pushing the REST GET/PUT endpoints from the control path
was exactly what we had in mind. WRT the direction I have no preference
(even though at the moment it's from manager to host and for simplicity
I wouldn't change it right away).
I am not sure if the current implementation is misleading but the fact
that download/uploadImage are something that don't belong to the control
path (regular APIs) should be clear for everyone.
--
Federico
11:59 a.m.
On 12/11/14 10:15 PM, Lucas Vandroux wrote:
Dear all,
I'm actually working to create a custom user interface plugin for oVirt
web administration application to let user upload iso files.
I'm in the very first stage of the project. I'm planning to use
angularjs with the ng-flow module <https://github.com/flowjs/ng-flow> on
the client-side and a java servlet using the ovirt-iso-uploader
<http://www.ovirt.org/OVirt_engine_tools#ovirt-iso-uploader> engine tool
on the server-side.
All my code is going to be on Github in the following repository
: iso-uploader-plugin
<https://github.com/ovirt-china/iso-uploader-plugin>;. You can also check
a more detailed version of the specifications on my wiki
<https://github.com/ovirt-china/iso-uploader-plugin/wiki/Specifications>;.
I'm writing to you guys to know if there is a way for us to collaborate
as you may also want to develop something like this to be integrated in
the oVirt Engine.
Best regards,
- Lucas Vandroux （冯凯）
Lucas,
I am glad to see someone finally picking this up.
I don't maintain the ISO uploader anymore but I can offer you some
suggestions that may help you with your effort.
1) The mount command which is used by the 'ovirt-iso-uploader' requires
root. Hence, the calling process must be root. If you shell out to the
'ovirt-iso-uploader' from a servlet running in Ovirt Engine the calling
process will not be root. Instead, it will be the user 'ovirt'. As
such, uploading a file will fail because the mount command will fail.
To circumvent this issue, I suggest you investigate creating a
consolehelper script to call the program as the user 'ovirt' and elevate
your privileges to root. I would avoid sudo for this purpose.
2) The plug-in you are creating will only work if Ovirt Engine can
actually reach the NFS server. AIUI, there are valid configurations
where Hypervisors can reach the NFS server but the Engine cannot. I am
not sure if this is still the case but you will want to gracefully
handle this.
3) SSH is easier. If you can SSH to the NFS server and upload the files
that way then you will not have to shell out to the
'ovirt-iso-uploader'. You can use the Java SSH library that ships with
oVirt. I would suggest you review lines in [1] so that you understand
the necessary file permissions. It is important to note; however, that
not all NFS server support SSH so this should not be the default
uploading mechanism.
HTH,
Keith
[1] http://goo.gl/0ihn8W
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
3:34 p.m.
On 12/15/2014 07:33 PM, Federico Simoncelli wrote:
----- Original Message -----
> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> To: "Federico Simoncelli" <fsimonce(a)redhat.com>
> Cc: "Nir Soffer" <nsoffer(a)redhat.com>, "devel"
<devel(a)ovirt.org>, "李建盛" <jiansheng.li(a)eayun.com>, "Lucas
Vandroux"
> <lucas.vandroux(a)eayun.com>, "Liron Aravot"
<laravot(a)redhat.com>, "潘礼洋" <liyang.pan(a)eayun.com>, "Michal
Skrivanek"
> <mskrivan(a)redhat.com>
> Sent: Monday, December 15, 2014 6:15:53 PM
> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>
>
>
> ----- Original Message -----
>> From: "Federico Simoncelli" <fsimonce(a)redhat.com>
>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
>> Cc: "Nir Soffer" <nsoffer(a)redhat.com>, "devel"
<devel(a)ovirt.org>, "李建盛"
>> <jiansheng.li(a)eayun.com>, "Lucas Vandroux"
>> <lucas.vandroux(a)eayun.com>, "Liron Aravot"
<laravot(a)redhat.com>, "潘礼洋"
>> <liyang.pan(a)eayun.com>, "Michal Skrivanek"
>> <mskrivan(a)redhat.com>
>> Sent: Monday, December 15, 2014 7:09:11 PM
>> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>>
>> ----- Original Message -----
>>> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>> To: "Nir Soffer" <nsoffer(a)redhat.com>
>>> Cc: "devel" <devel(a)ovirt.org>, "李建盛"
<jiansheng.li(a)eayun.com>, "Lucas
>>> Vandroux" <lucas.vandroux(a)eayun.com>, "Liron
>>> Aravot" <laravot(a)redhat.com>, "潘礼洋"
<liyang.pan(a)eayun.com>, "Michal
>>> Skrivanek" <mskrivan(a)redhat.com>
>>> Sent: Monday, December 15, 2014 5:52:36 PM
>>> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>>>
>>> ----- Original Message -----
>>>> From: "Nir Soffer" <nsoffer(a)redhat.com>
>>>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>>> Cc: "Itamar Heim" <iheim(a)redhat.com>, "devel"
<devel(a)ovirt.org>, "Lucas
>>>> Vandroux" <lucas.vandroux(a)eayun.com>, "李建盛"
>>>> <jiansheng.li(a)eayun.com>, "潘礼洋"
<liyang.pan(a)eayun.com>, "Michal
>>>> Skrivanek"
>>>> <mskrivan(a)redhat.com>, "Liron Aravot"
>>>> <laravot(a)redhat.com>
>>>> Sent: Monday, December 15, 2014 6:47:44 PM
>>>> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>>>>
>>>> ----- Original Message -----
>>>>> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>>>> To: "Itamar Heim" <iheim(a)redhat.com>
>>>>> Cc: "devel" <devel(a)ovirt.org>, "Lucas
Vandroux"
>>>>> <lucas.vandroux(a)eayun.com>,
>>>>> "李建盛" <jiansheng.li(a)eayun.com>, "潘礼洋"
>>>>> <liyang.pan(a)eayun.com>, "Michal Skrivanek"
<mskrivan(a)redhat.com>
>>>>> Sent: Sunday, December 14, 2014 11:47:26 PM
>>>>> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>>>>>
>>>>>
>>>>> using ssh and/or nfs to send artifacts to hosts is something we
>>>>> should
>>>>> avoid
>>>>> so using iso/image uploader tools are not a solution.
>>>>> vdsm should support uploading images using its own protocol based on
>>>>> the
>>>>> authentication between engine and vdsm, is it already?
>>>>
>>>> Vdsm does support upload over http/https directly to storage.
>>>>
>>>> This feature is used to store ovf backups on storage domains, and
>>>> probably
>>>> not very efficient, but may be good enough for now.
>>>>
>>>> See vdsm/rpc/BindingXMLRPC.py (do_PUT)
>>>
>>> thanks.
>>> I hear this function is not supported by the new jsonrpc, nor will it be
>>> supported when messaging will be used... so not sure if it is a good idea
>>> to
>>> add functionality on top of this one.
>>
>> The format (xmlrpc/jsonrpc) here is not much interesting, the interesting
>> part is the transport. In fact current download/uploadImage uses REST
>> GET/PUT for downloading/uploading the images (only the errors/messages are
>> reported with xmlrpc or eventually they could be reported with jsonrpc).
>>
>> By design they were not mixed with the other control APIs (because it's
>> not control, it's data). And indeed it cannot be transported with
>> messaging.
>>
>> Uploading/dowloading data to/from the host involves a data transport
>> (and http REST is the most commonly used). Which is exactly what you
>> need here, and it was in fact designed for this use case.
>
> there are plans to use messaging/broker to access hosts.
> this should abstract the physical location of the host.
> using direct connection to host in addition to broker is something that
> should be avoided.
Agreed, although when we discussed how to coherently move large data
from/to the hosts it became obvious that messaging/broker is not the
right tool.
> once solution may be to obtain connection information from the control
> channel, but one of the "problems" that will nice to be solved is to stop
> initiating connections from manager.
Retrieving/pushing the REST GET/PUT endpoints from the control path
was exactly what we had in mind. WRT the direction I have no preference
(even though at the moment it's from manager to host and for simplicity
I wouldn't change it right away).
I am not sure if the current implementation is misleading but the fact
that download/uploadImage are something that don't belong to the control
path (regular APIs) should be clear for everyone.
iirc, the current verbs allow vdsm to download or upload, not the
engine. not sure if this will work with "streaming" the images via the
engine, vs. having to 'store and forward' them.
4:27 p.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Federico Simoncelli" <fsimonce(a)redhat.com>, "Alon Bar-Lev"
<alonbl(a)redhat.com>
Cc: "devel" <devel(a)ovirt.org>, "李建盛"
<jiansheng.li(a)eayun.com>, "Lucas Vandroux"
<lucas.vandroux(a)eayun.com>, "Liron
Aravot" <laravot(a)redhat.com>, "潘礼洋" <liyang.pan(a)eayun.com>,
"Michal Skrivanek" <mskrivan(a)redhat.com>
Sent: Monday, December 15, 2014 10:34:51 PM
Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
On 12/15/2014 07:33 PM, Federico Simoncelli wrote:
>
>
> ----- Original Message -----
>> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
>> To: "Federico Simoncelli" <fsimonce(a)redhat.com>
>> Cc: "Nir Soffer" <nsoffer(a)redhat.com>, "devel"
<devel(a)ovirt.org>, "李建盛"
>> <jiansheng.li(a)eayun.com>, "Lucas Vandroux"
>> <lucas.vandroux(a)eayun.com>, "Liron Aravot"
<laravot(a)redhat.com>, "潘礼洋"
>> <liyang.pan(a)eayun.com>, "Michal Skrivanek"
>> <mskrivan(a)redhat.com>
>> Sent: Monday, December 15, 2014 6:15:53 PM
>> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>>
>>
>>
>> ----- Original Message -----
>>> From: "Federico Simoncelli" <fsimonce(a)redhat.com>
>>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>> Cc: "Nir Soffer" <nsoffer(a)redhat.com>, "devel"
<devel(a)ovirt.org>, "李建盛"
>>> <jiansheng.li(a)eayun.com>, "Lucas Vandroux"
>>> <lucas.vandroux(a)eayun.com>, "Liron Aravot"
<laravot(a)redhat.com>, "潘礼洋"
>>> <liyang.pan(a)eayun.com>, "Michal Skrivanek"
>>> <mskrivan(a)redhat.com>
>>> Sent: Monday, December 15, 2014 7:09:11 PM
>>> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>>>
>>> ----- Original Message -----
>>>> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>>> To: "Nir Soffer" <nsoffer(a)redhat.com>
>>>> Cc: "devel" <devel(a)ovirt.org>, "李建盛"
<jiansheng.li(a)eayun.com>, "Lucas
>>>> Vandroux" <lucas.vandroux(a)eayun.com>, "Liron
>>>> Aravot" <laravot(a)redhat.com>, "潘礼洋"
<liyang.pan(a)eayun.com>, "Michal
>>>> Skrivanek" <mskrivan(a)redhat.com>
>>>> Sent: Monday, December 15, 2014 5:52:36 PM
>>>> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>>>>
>>>> ----- Original Message -----
>>>>> From: "Nir Soffer" <nsoffer(a)redhat.com>
>>>>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>>>> Cc: "Itamar Heim" <iheim(a)redhat.com>,
"devel" <devel(a)ovirt.org>, "Lucas
>>>>> Vandroux" <lucas.vandroux(a)eayun.com>, "李建盛"
>>>>> <jiansheng.li(a)eayun.com>, "潘礼洋"
<liyang.pan(a)eayun.com>, "Michal
>>>>> Skrivanek"
>>>>> <mskrivan(a)redhat.com>, "Liron Aravot"
>>>>> <laravot(a)redhat.com>
>>>>> Sent: Monday, December 15, 2014 6:47:44 PM
>>>>> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>>>>> To: "Itamar Heim" <iheim(a)redhat.com>
>>>>>> Cc: "devel" <devel(a)ovirt.org>, "Lucas
Vandroux"
>>>>>> <lucas.vandroux(a)eayun.com>,
>>>>>> "李建盛" <jiansheng.li(a)eayun.com>, "潘礼洋"
>>>>>> <liyang.pan(a)eayun.com>, "Michal Skrivanek"
<mskrivan(a)redhat.com>
>>>>>> Sent: Sunday, December 14, 2014 11:47:26 PM
>>>>>> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>>>>>>
>>>>>>
>>>>>> using ssh and/or nfs to send artifacts to hosts is something we
>>>>>> should
>>>>>> avoid
>>>>>> so using iso/image uploader tools are not a solution.
>>>>>> vdsm should support uploading images using its own protocol
based on
>>>>>> the
>>>>>> authentication between engine and vdsm, is it already?
>>>>>
>>>>> Vdsm does support upload over http/https directly to storage.
>>>>>
>>>>> This feature is used to store ovf backups on storage domains, and
>>>>> probably
>>>>> not very efficient, but may be good enough for now.
>>>>>
>>>>> See vdsm/rpc/BindingXMLRPC.py (do_PUT)
>>>>
>>>> thanks.
>>>> I hear this function is not supported by the new jsonrpc, nor will it
be
>>>> supported when messaging will be used... so not sure if it is a good
>>>> idea
>>>> to
>>>> add functionality on top of this one.
>>>
>>> The format (xmlrpc/jsonrpc) here is not much interesting, the interesting
>>> part is the transport. In fact current download/uploadImage uses REST
>>> GET/PUT for downloading/uploading the images (only the errors/messages
>>> are
>>> reported with xmlrpc or eventually they could be reported with jsonrpc).
>>>
>>> By design they were not mixed with the other control APIs (because it's
>>> not control, it's data). And indeed it cannot be transported with
>>> messaging.
>>>
>>> Uploading/dowloading data to/from the host involves a data transport
>>> (and http REST is the most commonly used). Which is exactly what you
>>> need here, and it was in fact designed for this use case.
>>
>> there are plans to use messaging/broker to access hosts.
>> this should abstract the physical location of the host.
>> using direct connection to host in addition to broker is something that
>> should be avoided.
>
> Agreed, although when we discussed how to coherently move large data
> from/to the hosts it became obvious that messaging/broker is not the
> right tool.
>
>> once solution may be to obtain connection information from the control
>> channel, but one of the "problems" that will nice to be solved is to
stop
>> initiating connections from manager.
>
> Retrieving/pushing the REST GET/PUT endpoints from the control path
> was exactly what we had in mind. WRT the direction I have no preference
> (even though at the moment it's from manager to host and for simplicity
> I wouldn't change it right away).
>
> I am not sure if the current implementation is misleading but the fact
> that download/uploadImage are something that don't belong to the control
> path (regular APIs) should be clear for everyone.
iirc, the current verbs allow vdsm to download or upload, not the
engine. not sure if this will work with "streaming" the images via the
engine, vs. having to 'store and forward' them.
Using "download" would require 'store and forward'. On the other hand
upload should support streaming because engine (or its separate component)
would be just a (streaming) proxy between the client and vdsm.
--
Federico
4:32 p.m.
On 12/16/2014 12:27 AM, Federico Simoncelli wrote:
----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Federico Simoncelli" <fsimonce(a)redhat.com>, "Alon
Bar-Lev" <alonbl(a)redhat.com>
> Cc: "devel" <devel(a)ovirt.org>, "李建盛"
<jiansheng.li(a)eayun.com>, "Lucas Vandroux"
<lucas.vandroux(a)eayun.com>, "Liron
> Aravot" <laravot(a)redhat.com>, "潘礼洋"
<liyang.pan(a)eayun.com>, "Michal Skrivanek" <mskrivan(a)redhat.com>
> Sent: Monday, December 15, 2014 10:34:51 PM
> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>
> On 12/15/2014 07:33 PM, Federico Simoncelli wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>> To: "Federico Simoncelli" <fsimonce(a)redhat.com>
>>> Cc: "Nir Soffer" <nsoffer(a)redhat.com>, "devel"
<devel(a)ovirt.org>, "李建盛"
>>> <jiansheng.li(a)eayun.com>, "Lucas Vandroux"
>>> <lucas.vandroux(a)eayun.com>, "Liron Aravot"
<laravot(a)redhat.com>, "潘礼洋"
>>> <liyang.pan(a)eayun.com>, "Michal Skrivanek"
>>> <mskrivan(a)redhat.com>
>>> Sent: Monday, December 15, 2014 6:15:53 PM
>>> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Federico Simoncelli" <fsimonce(a)redhat.com>
>>>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>>> Cc: "Nir Soffer" <nsoffer(a)redhat.com>, "devel"
<devel(a)ovirt.org>, "李建盛"
>>>> <jiansheng.li(a)eayun.com>, "Lucas Vandroux"
>>>> <lucas.vandroux(a)eayun.com>, "Liron Aravot"
<laravot(a)redhat.com>, "潘礼洋"
>>>> <liyang.pan(a)eayun.com>, "Michal Skrivanek"
>>>> <mskrivan(a)redhat.com>
>>>> Sent: Monday, December 15, 2014 7:09:11 PM
>>>> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>>>>
>>>> ----- Original Message -----
>>>>> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>>>> To: "Nir Soffer" <nsoffer(a)redhat.com>
>>>>> Cc: "devel" <devel(a)ovirt.org>, "李建盛"
<jiansheng.li(a)eayun.com>, "Lucas
>>>>> Vandroux" <lucas.vandroux(a)eayun.com>, "Liron
>>>>> Aravot" <laravot(a)redhat.com>, "潘礼洋"
<liyang.pan(a)eayun.com>, "Michal
>>>>> Skrivanek" <mskrivan(a)redhat.com>
>>>>> Sent: Monday, December 15, 2014 5:52:36 PM
>>>>> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Nir Soffer" <nsoffer(a)redhat.com>
>>>>>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>>>>> Cc: "Itamar Heim" <iheim(a)redhat.com>,
"devel" <devel(a)ovirt.org>, "Lucas
>>>>>> Vandroux" <lucas.vandroux(a)eayun.com>, "李建盛"
>>>>>> <jiansheng.li(a)eayun.com>, "潘礼洋"
<liyang.pan(a)eayun.com>, "Michal
>>>>>> Skrivanek"
>>>>>> <mskrivan(a)redhat.com>, "Liron Aravot"
>>>>>> <laravot(a)redhat.com>
>>>>>> Sent: Monday, December 15, 2014 6:47:44 PM
>>>>>> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
>>>>>>> To: "Itamar Heim" <iheim(a)redhat.com>
>>>>>>> Cc: "devel" <devel(a)ovirt.org>, "Lucas
Vandroux"
>>>>>>> <lucas.vandroux(a)eayun.com>,
>>>>>>> "李建盛" <jiansheng.li(a)eayun.com>,
"潘礼洋"
>>>>>>> <liyang.pan(a)eayun.com>, "Michal Skrivanek"
<mskrivan(a)redhat.com>
>>>>>>> Sent: Sunday, December 14, 2014 11:47:26 PM
>>>>>>> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
>>>>>>>
>>>>>>>
>>>>>>> using ssh and/or nfs to send artifacts to hosts is something
we
>>>>>>> should
>>>>>>> avoid
>>>>>>> so using iso/image uploader tools are not a solution.
>>>>>>> vdsm should support uploading images using its own protocol
based on
>>>>>>> the
>>>>>>> authentication between engine and vdsm, is it already?
>>>>>>
>>>>>> Vdsm does support upload over http/https directly to storage.
>>>>>>
>>>>>> This feature is used to store ovf backups on storage domains,
and
>>>>>> probably
>>>>>> not very efficient, but may be good enough for now.
>>>>>>
>>>>>> See vdsm/rpc/BindingXMLRPC.py (do_PUT)
>>>>>
>>>>> thanks.
>>>>> I hear this function is not supported by the new jsonrpc, nor will it
be
>>>>> supported when messaging will be used... so not sure if it is a good
>>>>> idea
>>>>> to
>>>>> add functionality on top of this one.
>>>>
>>>> The format (xmlrpc/jsonrpc) here is not much interesting, the
interesting
>>>> part is the transport. In fact current download/uploadImage uses REST
>>>> GET/PUT for downloading/uploading the images (only the errors/messages
>>>> are
>>>> reported with xmlrpc or eventually they could be reported with jsonrpc).
>>>>
>>>> By design they were not mixed with the other control APIs (because
it's
>>>> not control, it's data). And indeed it cannot be transported with
>>>> messaging.
>>>>
>>>> Uploading/dowloading data to/from the host involves a data transport
>>>> (and http REST is the most commonly used). Which is exactly what you
>>>> need here, and it was in fact designed for this use case.
>>>
>>> there are plans to use messaging/broker to access hosts.
>>> this should abstract the physical location of the host.
>>> using direct connection to host in addition to broker is something that
>>> should be avoided.
>>
>> Agreed, although when we discussed how to coherently move large data
>> from/to the hosts it became obvious that messaging/broker is not the
>> right tool.
>>
>>> once solution may be to obtain connection information from the control
>>> channel, but one of the "problems" that will nice to be solved is
to stop
>>> initiating connections from manager.
>>
>> Retrieving/pushing the REST GET/PUT endpoints from the control path
>> was exactly what we had in mind. WRT the direction I have no preference
>> (even though at the moment it's from manager to host and for simplicity
>> I wouldn't change it right away).
>>
>> I am not sure if the current implementation is misleading but the fact
>> that download/uploadImage are something that don't belong to the control
>> path (regular APIs) should be clear for everyone.
>
>
> iirc, the current verbs allow vdsm to download or upload, not the
> engine. not sure if this will work with "streaming" the images via the
> engine, vs. having to 'store and forward' them.
Using "download" would require 'store and forward'. On the other hand
upload should support streaming because engine (or its separate component)
would be just a (streaming) proxy between the client and vdsm.
I thought 'upload' is vdsm pushing to say, glance. not accepting from
engine?
4:50 p.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Federico Simoncelli" <fsimonce(a)redhat.com>
Cc: "Alon Bar-Lev" <alonbl(a)redhat.com>, "devel"
<devel(a)ovirt.org>, "李建盛" <jiansheng.li(a)eayun.com>, "Lucas
Vandroux"
<lucas.vandroux(a)eayun.com>, "Liron Aravot" <laravot(a)redhat.com>,
"潘礼洋" <liyang.pan(a)eayun.com>, "Michal Skrivanek"
<mskrivan(a)redhat.com>
Sent: Monday, December 15, 2014 11:32:47 PM
Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files
On 12/16/2014 12:27 AM, Federico Simoncelli wrote:
>>
>>
>> iirc, the current verbs allow vdsm to download or upload, not the
>> engine. not sure if this will work with "streaming" the images via
the
>> engine, vs. having to 'store and forward' them.
>
> Using "download" would require 'store and forward'. On the other
hand
> upload should support streaming because engine (or its separate component)
> would be just a (streaming) proxy between the client and vdsm.
>
I thought 'upload' is vdsm pushing to say, glance. not accepting from
engine?
Yeah it's confusing. Those are different upload/download verbs that
are not involving data to/from engine at all.
Basically those are regular tasks: upload or download an image to/from
an http server. They go through control path because data path is
between vdsm and the remote http server.
The REST api that we're discussing here instead is the (let's say)
glance-like interface that was designed exactly for this download
and upload image use-case from the calling endpoint (it is used for
the ovf files and I think hosted-engine is using it to inject the
engine appliance).
In mind we had streaming, not sure how much of that ended up in
real code (schedule was extremely tight at that time).
--
Federico
5:08 p.m.
On 12/15/2014 07:59 PM, Keith Robertson wrote:
On 12/11/14 10:15 PM, Lucas Vandroux wrote:
> Dear all,
>
> I'm actually working to create a custom user interface plugin for oVirt
> web administration application to let user upload iso files.
>
> I'm in the very first stage of the project. I'm planning to use
> angularjs with the ng-flow module <https://github.com/flowjs/ng-flow> on
> the client-side and a java servlet using the ovirt-iso-uploader
> <http://www.ovirt.org/OVirt_engine_tools#ovirt-iso-uploader> engine tool
> on the server-side.
>
> All my code is going to be on Github in the following repository
> : iso-uploader-plugin
> <https://github.com/ovirt-china/iso-uploader-plugin>;. You can also check
> a more detailed version of the specifications on my wiki
> <https://github.com/ovirt-china/iso-uploader-plugin/wiki/Specifications>;.
>
> I'm writing to you guys to know if there is a way for us to collaborate
> as you may also want to develop something like this to be integrated in
> the oVirt Engine.
>
> Best regards,
>
> - Lucas Vandroux （冯凯）
>
Lucas,
I am glad to see someone finally picking this up.
I don't maintain the ISO uploader anymore but I can offer you some
suggestions that may help you with your effort.
1) The mount command which is used by the 'ovirt-iso-uploader' requires
root. Hence, the calling process must be root. If you shell out to the
'ovirt-iso-uploader' from a servlet running in Ovirt Engine the calling
process will not be root. Instead, it will be the user 'ovirt'. As
such, uploading a file will fail because the mount command will fail.
To circumvent this issue, I suggest you investigate creating a
consolehelper script to call the program as the user 'ovirt' and elevate
your privileges to root. I would avoid sudo for this purpose.
2) The plug-in you are creating will only work if Ovirt Engine can
actually reach the NFS server. AIUI, there are valid configurations
where Hypervisors can reach the NFS server but the Engine cannot. I am
not sure if this is still the case but you will want to gracefully
handle this.
3) SSH is easier. If you can SSH to the NFS server and upload the files
that way then you will not have to shell out to the
'ovirt-iso-uploader'. You can use the Java SSH library that ships with
oVirt. I would suggest you review lines in [1] so that you understand
the necessary file permissions. It is important to note; however, that
not all NFS server support SSH so this should not be the default
uploading mechanism.
though as mentioned on the thread, we'd really love to see this done via
upload to storage via vdsm communication.
HTH,
Keith
[1] http://goo.gl/0ihn8W
>
>
> _______________________________________________
> 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
3:53 a.m.
This is a multi-part message in MIME format.
------=_NextPart_54AA5F1A_0AA2EED0_6B36A1B0
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: base64
RGVhciBhbGwsDQoNCg0KVGhhbmtzIGEgbG90IGZvciBhbGwgeW91ciBmZWVkYmFjaywgaXQg
aXMgaGVscGluZyB1cyBhIGxvdC4gV2Ugd2lsbCBsZXQgeW91IGtub3cgYWJvdXQgb3VyIHBy
b2dyZXNzLg0KDQoNCkJlc3QgcmVnYXJkcywNCg0KDQotIEx1Y2FzIFZhbmRyb3V4IOWGr+WH
ryAgDQoNCiANCiANCi0tLS0tLS0tLS0tLS0tLS0tLSBPcmlnaW5hbCAtLS0tLS0tLS0tLS0t
LS0tLS0NCkZyb206ICJJdGFtYXIgSGVpbSI7IA0KRGF0ZTogMjAxNOW5tDEy5pyIMTbml6Uo
5pif5pyf5LqMKSDkuIrljYg3OjA4DQpUbzogIktlaXRoIFJvYmVydHNvbiI7ICJWYW5kcm91
eCBMdWNhcyI7ICJkZXZlbCI7IA0KU3ViamVjdDogUmU6IFtvdmlydC1kZXZlbF0gVUkgUGx1
Z2luIHRvIFVwbG9hZCBJU08gRmlsZXMNCg0KIA0KT24gMTIvMTUvMjAxNCAwNzo1OSBQTSwg
S2VpdGggUm9iZXJ0c29uIHdyb3RlOg0KPg0KPiBPbiAxMi8xMS8xNCAxMDoxNSBQTSwgTHVj
YXMgVmFuZHJvdXggd3JvdGU6DQo+PiBEZWFyIGFsbCwNCj4+DQo+PiBJJ20gYWN0dWFsbHkg
d29ya2luZyB0byBjcmVhdGUgYSBjdXN0b20gdXNlciBpbnRlcmZhY2UgcGx1Z2luIGZvciBv
VmlydA0KPj4gd2ViIGFkbWluaXN0cmF0aW9uIGFwcGxpY2F0aW9uIHRvIGxldCB1c2VyIHVw
bG9hZCBpc28gZmlsZXMuDQo+Pg0KPj4gSSdtIGluIHRoZSB2ZXJ5IGZpcnN0IHN0YWdlIG9m
IHRoZSBwcm9qZWN0LiBJJ20gcGxhbm5pbmcgdG8gdXNlDQo+PiBhbmd1bGFyanMgd2l0aCB0
aGUgbmctZmxvdyBtb2R1bGUgPGh0dHBzOi8vZ2l0aHViLmNvbS9mbG93anMvbmctZmxvdz47
IG9uDQo+PiB0aGUgY2xpZW50LXNpZGUgYW5kIGEgamF2YSBzZXJ2bGV0IHVzaW5nIHRoZSBv
dmlydC1pc28tdXBsb2FkZXINCj4+IDxodHRwOi8vd3d3Lm92aXJ0Lm9yZy9PVmlydF9lbmdp
bmVfdG9vbHMjb3ZpcnQtaXNvLXVwbG9hZGVyJmd0OyBlbmdpbmUgdG9vbA0KPj4gb24gdGhl
IHNlcnZlci1zaWRlLg0KPj4NCj4+IEFsbCBteSBjb2RlIGlzIGdvaW5nIHRvIGJlIG9uIEdp
dGh1YiBpbiB0aGUgZm9sbG93aW5nIHJlcG9zaXRvcnkNCj4+IDogaXNvLXVwbG9hZGVyLXBs
dWdpbg0KPj4gPGh0dHBzOi8vZ2l0aHViLmNvbS9vdmlydC1jaGluYS9pc28tdXBsb2FkZXIt
cGx1Z2luPi4gWW91IGNhbiBhbHNvIGNoZWNrDQo+PiBhIG1vcmUgZGV0YWlsZWQgdmVyc2lv
biBvZiB0aGUgc3BlY2lmaWNhdGlvbnMgb24gbXkgd2lraQ0KPj4gPGh0dHBzOi8vZ2l0aHVi
LmNvbS9vdmlydC1jaGluYS9pc28tdXBsb2FkZXItcGx1Z2luL3dpa2kvU3BlY2lmaWNhdGlv
bnMmZ3Q7Lg0KPj4NCj4+IEknbSB3cml0aW5nIHRvIHlvdSBndXlzIHRvIGtub3cgaWYgdGhl
cmUgaXMgYSB3YXkgZm9yIHVzIHRvIGNvbGxhYm9yYXRlDQo+PiBhcyB5b3UgbWF5IGFsc28g
d2FudCB0byBkZXZlbG9wIHNvbWV0aGluZyBsaWtlIHRoaXMgdG8gYmUgaW50ZWdyYXRlZCBp
bg0KPj4gdGhlIG9WaXJ0IEVuZ2luZS4NCj4+DQo+PiBCZXN0IHJlZ2FyZHMsDQo+Pg0KPj4g
LSBMdWNhcyBWYW5kcm91eCDvvIjlhq/lh6/vvIkNCj4+DQo+DQo+IEx1Y2FzLA0KPg0KPiBJ
IGFtIGdsYWQgdG8gc2VlIHNvbWVvbmUgZmluYWxseSBwaWNraW5nIHRoaXMgdXAuDQo+DQo+
IEkgZG9uJ3QgbWFpbnRhaW4gdGhlIElTTyB1cGxvYWRlciBhbnltb3JlIGJ1dCBJIGNhbiBv
ZmZlciB5b3Ugc29tZQ0KPiBzdWdnZXN0aW9ucyB0aGF0IG1heSBoZWxwIHlvdSB3aXRoIHlv
dXIgZWZmb3J0Lg0KPg0KPiAxKSBUaGUgbW91bnQgY29tbWFuZCB3aGljaCBpcyB1c2VkIGJ5
IHRoZSAnb3ZpcnQtaXNvLXVwbG9hZGVyJyByZXF1aXJlcw0KPiByb290LiAgSGVuY2UsIHRo
ZSBjYWxsaW5nIHByb2Nlc3MgbXVzdCBiZSByb290LiAgSWYgeW91IHNoZWxsIG91dCB0byB0
aGUNCj4gJ292aXJ0LWlzby11cGxvYWRlcicgZnJvbSBhIHNlcnZsZXQgcnVubmluZyBpbiBP
dmlydCBFbmdpbmUgdGhlIGNhbGxpbmcNCj4gcHJvY2VzcyB3aWxsIG5vdCBiZSByb290LiAg
SW5zdGVhZCwgaXQgd2lsbCBiZSB0aGUgdXNlciAnb3ZpcnQnLiAgQXMNCj4gc3VjaCwgdXBs
b2FkaW5nIGEgZmlsZSB3aWxsIGZhaWwgYmVjYXVzZSB0aGUgbW91bnQgY29tbWFuZCB3aWxs
IGZhaWwuDQo+DQo+IFRvIGNpcmN1bXZlbnQgdGhpcyBpc3N1ZSwgSSBzdWdnZXN0IHlvdSBp
bnZlc3RpZ2F0ZSBjcmVhdGluZyBhDQo+IGNvbnNvbGVoZWxwZXIgc2NyaXB0IHRvIGNhbGwg
dGhlIHByb2dyYW0gYXMgdGhlIHVzZXIgJ292aXJ0JyBhbmQgZWxldmF0ZQ0KPiB5b3VyIHBy
aXZpbGVnZXMgdG8gcm9vdC4gIEkgd291bGQgYXZvaWQgc3VkbyBmb3IgdGhpcyBwdXJwb3Nl
Lg0KPg0KPiAyKSBUaGUgcGx1Zy1pbiB5b3UgYXJlIGNyZWF0aW5nIHdpbGwgb25seSB3b3Jr
IGlmIE92aXJ0IEVuZ2luZSBjYW4NCj4gYWN0dWFsbHkgcmVhY2ggdGhlIE5GUyBzZXJ2ZXIu
ICBBSVVJLCB0aGVyZSBhcmUgdmFsaWQgY29uZmlndXJhdGlvbnMNCj4gd2hlcmUgSHlwZXJ2
aXNvcnMgY2FuIHJlYWNoIHRoZSBORlMgc2VydmVyIGJ1dCB0aGUgRW5naW5lIGNhbm5vdC4g
IEkgYW0NCj4gbm90IHN1cmUgaWYgdGhpcyBpcyBzdGlsbCB0aGUgY2FzZSBidXQgeW91IHdp
bGwgd2FudCB0byBncmFjZWZ1bGx5DQo+IGhhbmRsZSB0aGlzLg0KPg0KPiAzKSBTU0ggaXMg
ZWFzaWVyLiAgSWYgeW91IGNhbiBTU0ggdG8gdGhlIE5GUyBzZXJ2ZXIgYW5kIHVwbG9hZCB0
aGUgZmlsZXMNCj4gdGhhdCB3YXkgdGhlbiB5b3Ugd2lsbCBub3QgaGF2ZSB0byBzaGVsbCBv
dXQgdG8gdGhlDQo+ICdvdmlydC1pc28tdXBsb2FkZXInLiAgWW91IGNhbiB1c2UgdGhlIEph
dmEgU1NIIGxpYnJhcnkgdGhhdCBzaGlwcyB3aXRoDQo+IG9WaXJ0LiAgSSB3b3VsZCBzdWdn
ZXN0IHlvdSByZXZpZXcgbGluZXMgaW4gWzFdIHNvIHRoYXQgeW91IHVuZGVyc3RhbmQNCj4g
dGhlIG5lY2Vzc2FyeSBmaWxlIHBlcm1pc3Npb25zLiAgSXQgaXMgaW1wb3J0YW50IHRvIG5v
dGU7IGhvd2V2ZXIsIHRoYXQNCj4gbm90IGFsbCBORlMgc2VydmVyIHN1cHBvcnQgU1NIIHNv
IHRoaXMgc2hvdWxkIG5vdCBiZSB0aGUgZGVmYXVsdA0KPiB1cGxvYWRpbmcgbWVjaGFuaXNt
Lg0KPg0KDQp0aG91Z2ggYXMgbWVudGlvbmVkIG9uIHRoZSB0aHJlYWQsIHdlJ2QgcmVhbGx5
IGxvdmUgdG8gc2VlIHRoaXMgZG9uZSB2aWEgDQp1cGxvYWQgdG8gc3RvcmFnZSB2aWEgdmRz
bSBjb21tdW5pY2F0aW9uLg0KDQo+IEhUSCwNCj4gS2VpdGgNCj4NCj4gWzFdIGh0dHA6Ly9n
b28uZ2wvMGlobjhXDQo+DQo+DQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBEZXZlbCBtYWlsaW5nIGxpc3QNCj4+IERl
dmVsQG92aXJ0Lm9yZw0KPj4gaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2RldmVsDQo+Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPiBEZXZlbCBtYWlsaW5nIGxpc3QNCj4gRGV2ZWxAb3ZpcnQub3JnDQo+
IGh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXZlbA0KPg==
------=_NextPart_54AA5F1A_0AA2EED0_6B36A1B0
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: base64
PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6VmVyZGFuYTtmb250LXNpemU6MTRweDtjb2xvcjoj
MDAwOyI+PGRpdj48ZGl2PkRlYXIgYWxsLDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhh
bmtzIGEgbG90IGZvciBhbGwgeW91ciBmZWVkYmFjaywgaXQgaXMgaGVscGluZyB1cyBhIGxv
dC4gV2Ugd2lsbCBsZXQgeW91IGtub3cgYWJvdXQgb3VyIHByb2dyZXNzLjwvZGl2PjxkaXY+
PGJyPjwvZGl2PjxkaXY+QmVzdCByZWdhcmRzLDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+
LSBMdWNhcyBWYW5kcm91eCDlhq/lh68gJm5ic3A7PC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0i
Zm9udDpWZXJkYW5hIG5vcm1hbCAxNHB4O2NvbG9yOiMwMDA7cGFkZGluZzo4cHggMHB4OyI+
PGRpdj4mbmJzcDs8L2Rpdj48ZGl2PiZuYnNwOzwvZGl2PjxkaXYgc3R5bGU9IkZPTlQtU0la
RTogMTJweDtGT05ULUZBTUlMWTogQXJpYWwgTmFycm93O3BhZGRpbmc6MnB4IDAgMnB4IDA7
Ij4tLS0tLS0tLS0tLS0tLS0tLS0mbmJzcDtPcmlnaW5hbCZuYnNwOy0tLS0tLS0tLS0tLS0t
LS0tLTwvZGl2PjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTJweDtiYWNrZ3JvdW5kOiNlZmVm
ZWY7cGFkZGluZzo4cHg7Ij48ZGl2PjxiPkZyb206PC9iPiAiSXRhbWFyIEhlaW0iPGloZWlt
QHJlZGhhdC5jb20+OyA8L2Rpdj48ZGl2PjxiPkRhdGU6PC9iPiAyMDE05bm0MTLmnIgxNuaX
pSjmmJ/mnJ/kuowpIOS4iuWNiDc6MDg8L2Rpdj48ZGl2PjxiPlRvOjwvYj4gIktlaXRoIFJv
YmVydHNvbiI8a3JvYmVydHNAcmVkaGF0LmNvbT47ICJWYW5kcm91eCBMdWNhcyI8bHVjYXMu
dmFuZHJvdXhAZWF5dW4uY29tPjsgImRldmVsIjxkZXZlbEBvdmlydC5vcmc+OyA8L2Rpdj48
ZGl2PjxiPlN1YmplY3Q6PC9iPiBSZTogW292aXJ0LWRldmVsXSBVSSBQbHVnaW4gdG8gVXBs
b2FkIElTTyBGaWxlczwvZGl2PjwvZGl2PjxkaXY+Jm5ic3A7PC9kaXY+T24gMTIvMTUvMjAx
NCAwNzo1OSBQTSwgS2VpdGggUm9iZXJ0c29uIHdyb3RlOjxicj4mZ3Q7PGJyPiZndDsgT24g
MTIvMTEvMTQgMTA6MTUgUE0sIEx1Y2FzIFZhbmRyb3V4IHdyb3RlOjxicj4mZ3Q7Jmd0OyBE
ZWFyIGFsbCw8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgSSdtIGFjdHVhbGx5IHdvcmtpbmcg
dG8gY3JlYXRlIGEgY3VzdG9tIHVzZXIgaW50ZXJmYWNlIHBsdWdpbiBmb3Igb1ZpcnQ8YnI+
Jmd0OyZndDsgd2ViIGFkbWluaXN0cmF0aW9uIGFwcGxpY2F0aW9uIHRvIGxldCB1c2VyIHVw
bG9hZCBpc28gZmlsZXMuPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IEknbSBpbiB0aGUgdmVy
eSBmaXJzdCBzdGFnZSBvZiB0aGUgcHJvamVjdC4gSSdtIHBsYW5uaW5nIHRvIHVzZTxicj4m
Z3Q7Jmd0OyBhbmd1bGFyanMgd2l0aCB0aGUgbmctZmxvdyBtb2R1bGUgJmx0OzxhIGhyZWY9
Imh0dHBzOi8vZ2l0aHViLmNvbS9mbG93anMvbmctZmxvdyZndDsiIHRhcmdldD0iX2JsYW5r
Ij5odHRwczovL2dpdGg8d2JyPnViLmNvbS9mbG93ajx3YnI+cy9uZy1mbG93Jmd0Ozx3YnI+
OzwvYT4gb248YnI+Jmd0OyZndDsgdGhlIGNsaWVudC1zaWRlIGFuZCBhIGphdmEgc2Vydmxl
dCB1c2luZyB0aGUgb3ZpcnQtaXNvLXVwbG9hZGVyPGJyPiZndDsmZ3Q7ICZsdDs8YSBocmVm
PSJodHRwOi8vd3d3Lm92aXJ0Lm9yZy9PVmlydF9lbmdpbmVfdG9vbHMjb3ZpcnQtaXNvLXVw
bG9hZGVyJmd0OyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cubzx3YnI+dmlydC5vcmcv
T1ZpPHdicj5ydF9lbmdpbmVfdG88d2JyPm9scyNvdmlydC1pczx3YnI+by11cGxvYWRlciZh
bXA7Zzx3YnI+dDs8L2E+IGVuZ2luZSB0b29sPGJyPiZndDsmZ3Q7IG9uIHRoZSBzZXJ2ZXIt
c2lkZS48YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgQWxsIG15IGNvZGUgaXMgZ29pbmcgdG8g
YmUgb24gR2l0aHViIGluIHRoZSBmb2xsb3dpbmcgcmVwb3NpdG9yeTxicj4mZ3Q7Jmd0OyA6
IGlzby11cGxvYWRlci1wbHVnaW48YnI+Jmd0OyZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8v
Z2l0aHViLmNvbS9vdmlydC1jaGluYS9pc28tdXBsb2FkZXItcGx1Z2luJmd0Oy4iIHRhcmdl
dD0iX2JsYW5rIj5odHRwczovL2dpdGg8d2JyPnViLmNvbS9vdmlydDx3YnI+LWNoaW5hL2lz
by11PHdicj5wbG9hZGVyLXBsdWc8d2JyPmluJmd0Oy48L2E+IFlvdSBjYW4gYWxzbyBjaGVj
azxicj4mZ3Q7Jmd0OyBhIG1vcmUgZGV0YWlsZWQgdmVyc2lvbiBvZiB0aGUgc3BlY2lmaWNh
dGlvbnMgb24gbXkgd2lraTxicj4mZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9naXRo
dWIuY29tL292aXJ0LWNoaW5hL2lzby11cGxvYWRlci1wbHVnaW4vd2lraS9TcGVjaWZpY2F0
aW9ucyZndDsuIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRoPHdicj51Yi5jb20vb3Zp
cnQ8d2JyPi1jaGluYS9pc28tdTx3YnI+cGxvYWRlci1wbHVnPHdicj5pbi93aWtpL1NwZWM8
d2JyPmlmaWNhdGlvbnMmYW1wO2c8d2JyPnQ7LjwvYT48YnI+Jmd0OyZndDs8YnI+Jmd0OyZn
dDsgSSdtIHdyaXRpbmcgdG8geW91IGd1eXMgdG8ga25vdyBpZiB0aGVyZSBpcyBhIHdheSBm
b3IgdXMgdG8gY29sbGFib3JhdGU8YnI+Jmd0OyZndDsgYXMgeW91IG1heSBhbHNvIHdhbnQg
dG8gZGV2ZWxvcCBzb21ldGhpbmcgbGlrZSB0aGlzIHRvIGJlIGludGVncmF0ZWQgaW48YnI+
Jmd0OyZndDsgdGhlIG9WaXJ0IEVuZ2luZS48YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgQmVz
dCByZWdhcmRzLDxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyAtIEx1Y2FzIFZhbmRyb3V4IO+8
iOWGr+WHr++8iTxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7PGJyPiZndDsgTHVjYXMsPGJyPiZndDs8
YnI+Jmd0OyBJIGFtIGdsYWQgdG8gc2VlIHNvbWVvbmUgZmluYWxseSBwaWNraW5nIHRoaXMg
dXAuPGJyPiZndDs8YnI+Jmd0OyBJIGRvbid0IG1haW50YWluIHRoZSBJU08gdXBsb2FkZXIg
YW55bW9yZSBidXQgSSBjYW4gb2ZmZXIgeW91IHNvbWU8YnI+Jmd0OyBzdWdnZXN0aW9ucyB0
aGF0IG1heSBoZWxwIHlvdSB3aXRoIHlvdXIgZWZmb3J0Ljxicj4mZ3Q7PGJyPiZndDsgMSkg
VGhlIG1vdW50IGNvbW1hbmQgd2hpY2ggaXMgdXNlZCBieSB0aGUgJ292aXJ0LWlzby11cGxv
YWRlcicgcmVxdWlyZXM8YnI+Jmd0OyByb290LiZuYnNwOyBIZW5jZSwgdGhlIGNhbGxpbmcg
cHJvY2VzcyBtdXN0IGJlIHJvb3QuJm5ic3A7IElmIHlvdSBzaGVsbCBvdXQgdG8gdGhlPGJy
PiZndDsgJ292aXJ0LWlzby11cGxvYWRlcicgZnJvbSBhIHNlcnZsZXQgcnVubmluZyBpbiBP
dmlydCBFbmdpbmUgdGhlIGNhbGxpbmc8YnI+Jmd0OyBwcm9jZXNzIHdpbGwgbm90IGJlIHJv
b3QuJm5ic3A7IEluc3RlYWQsIGl0IHdpbGwgYmUgdGhlIHVzZXIgJ292aXJ0Jy4mbmJzcDsg
QXM8YnI+Jmd0OyBzdWNoLCB1cGxvYWRpbmcgYSBmaWxlIHdpbGwgZmFpbCBiZWNhdXNlIHRo
ZSBtb3VudCBjb21tYW5kIHdpbGwgZmFpbC48YnI+Jmd0Ozxicj4mZ3Q7IFRvIGNpcmN1bXZl
bnQgdGhpcyBpc3N1ZSwgSSBzdWdnZXN0IHlvdSBpbnZlc3RpZ2F0ZSBjcmVhdGluZyBhPGJy
PiZndDsgY29uc29sZWhlbHBlciBzY3JpcHQgdG8gY2FsbCB0aGUgcHJvZ3JhbSBhcyB0aGUg
dXNlciAnb3ZpcnQnIGFuZCBlbGV2YXRlPGJyPiZndDsgeW91ciBwcml2aWxlZ2VzIHRvIHJv
b3QuJm5ic3A7IEkgd291bGQgYXZvaWQgc3VkbyBmb3IgdGhpcyBwdXJwb3NlLjxicj4mZ3Q7
PGJyPiZndDsgMikgVGhlIHBsdWctaW4geW91IGFyZSBjcmVhdGluZyB3aWxsIG9ubHkgd29y
ayBpZiBPdmlydCBFbmdpbmUgY2FuPGJyPiZndDsgYWN0dWFsbHkgcmVhY2ggdGhlIE5GUyBz
ZXJ2ZXIuJm5ic3A7IEFJVUksIHRoZXJlIGFyZSB2YWxpZCBjb25maWd1cmF0aW9uczxicj4m
Z3Q7IHdoZXJlIEh5cGVydmlzb3JzIGNhbiByZWFjaCB0aGUgTkZTIHNlcnZlciBidXQgdGhl
IEVuZ2luZSBjYW5ub3QuJm5ic3A7IEkgYW08YnI+Jmd0OyBub3Qgc3VyZSBpZiB0aGlzIGlz
IHN0aWxsIHRoZSBjYXNlIGJ1dCB5b3Ugd2lsbCB3YW50IHRvIGdyYWNlZnVsbHk8YnI+Jmd0
OyBoYW5kbGUgdGhpcy48YnI+Jmd0Ozxicj4mZ3Q7IDMpIFNTSCBpcyBlYXNpZXIuJm5ic3A7
IElmIHlvdSBjYW4gU1NIIHRvIHRoZSBORlMgc2VydmVyIGFuZCB1cGxvYWQgdGhlIGZpbGVz
PGJyPiZndDsgdGhhdCB3YXkgdGhlbiB5b3Ugd2lsbCBub3QgaGF2ZSB0byBzaGVsbCBvdXQg
dG8gdGhlPGJyPiZndDsgJ292aXJ0LWlzby11cGxvYWRlcicuJm5ic3A7IFlvdSBjYW4gdXNl
IHRoZSBKYXZhIFNTSCBsaWJyYXJ5IHRoYXQgc2hpcHMgd2l0aDxicj4mZ3Q7IG9WaXJ0LiZu
YnNwOyBJIHdvdWxkIHN1Z2dlc3QgeW91IHJldmlldyBsaW5lcyBpbiBbMV0gc28gdGhhdCB5
b3UgdW5kZXJzdGFuZDxicj4mZ3Q7IHRoZSBuZWNlc3NhcnkgZmlsZSBwZXJtaXNzaW9ucy4m
bmJzcDsgSXQgaXMgaW1wb3J0YW50IHRvIG5vdGU7IGhvd2V2ZXIsIHRoYXQ8YnI+Jmd0OyBu
b3QgYWxsIE5GUyBzZXJ2ZXIgc3VwcG9ydCBTU0ggc28gdGhpcyBzaG91bGQgbm90IGJlIHRo
ZSBkZWZhdWx0PGJyPiZndDsgdXBsb2FkaW5nIG1lY2hhbmlzbS48YnI+Jmd0Ozxicj48YnI+
dGhvdWdoIGFzIG1lbnRpb25lZCBvbiB0aGUgdGhyZWFkLCB3ZSdkIHJlYWxseSBsb3ZlIHRv
IHNlZSB0aGlzIGRvbmUgdmlhIDxicj51cGxvYWQgdG8gc3RvcmFnZSB2aWEgdmRzbSBjb21t
dW5pY2F0aW9uLjxicj48YnI+Jmd0OyBIVEgsPGJyPiZndDsgS2VpdGg8YnI+Jmd0Ozxicj4m
Z3Q7IFsxXSA8YSBocmVmPSJodHRwOi8vZ29vLmdsLzBpaG44VyIgdGFyZ2V0PSJfYmxhbmsi
Pmh0dHA6Ly9nb28uZzx3YnI+bC8waWhuOFc8L2E+PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7
Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyBEZXZlbCBtYWlsaW5nIGxpc3Q8
YnI+Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9tYWlsLmdvb2dsZS5jb20vbWFpbC8/dmll
dz1jbSZhbXA7ZnM9MSZhbXA7dGY9MSZhbXA7dG89RGV2ZWxAb3ZpcnQub3JnIiB0YXJnZXQ9
Il9ibGFuayI+RGV2ZWxAb3ZpcnQuPHdicj5vcmc8L2E+PGJyPiZndDsmZ3Q7IDxhIGhyZWY9
Imh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXZlbCIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHA6Ly9saXN0czx3YnI+Lm92aXJ0Lm9yZy9tPHdicj5haWxtYW4vbGlz
dGk8d2JyPm5mby9kZXZlbDwvYT48YnI+Jmd0OyZndDs8YnI+Jmd0OyBfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7IERldmVsIG1haWxp
bmcgbGlzdDxicj4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vbWFpbC5nb29nbGUuY29tL21haWwv
P3ZpZXc9Y20mYW1wO2ZzPTEmYW1wO3RmPTEmYW1wO3RvPURldmVsQG92aXJ0Lm9yZyIgdGFy
Z2V0PSJfYmxhbmsiPkRldmVsQG92aXJ0Ljx3YnI+b3JnPC9hPjxicj4mZ3Q7IDxhIGhyZWY9
Imh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXZlbCIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHA6Ly9saXN0czx3YnI+Lm92aXJ0Lm9yZy9tPHdicj5haWxtYW4vbGlz
dGk8d2JyPm5mby9kZXZlbDwvYT48YnI+Jmd0Ozxicj4gIDwhLS08IVtlbmRpZl0tLT48c3R5
bGU+PC9zdHlsZT48L2Rpdj48L2Rpdj4=
------=_NextPart_54AA5F1A_0AA2EED0_6B36A1B0--
3397
days inactive
3421
days old
16 comments
7 participants
participants (7)
-
Alon Bar-Lev -
Federico Simoncelli -
Itamar Heim -
Keith Robertson -
Lucas Vandroux -
Michal Skrivanek -
Nir Soffer