UI Plugin to Upload ISO Files
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--
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.
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Lucas Vandroux" <lucas.vandroux@eayun.com>, "devel" <devel@ovirt.org>, "潘礼洋" <liyang.pan@eayun.com>, "李建盛" <jiansheng.li@eayun.com> Cc: "Michal Skrivanek" <mskrivan@redhat.com>, "Scott Herold" <sherold@redhat.com>, "Allon Mureinik" <amureini@redhat.com>, "Federico Simoncelli" <fsimonce@redhat.com>, "Barak Azulay" <bazulay@redhat.com>, "Brian Proffitt" <bproffit@redhat.com>, "Alon Bar-Lev" <alonbl@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
On Dec 14, 2014, at 22:47 , Alon Bar-Lev <alonbl@redhat.com> wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Lucas Vandroux" <lucas.vandroux@eayun.com>, "devel" <devel@ovirt.org>, "潘礼洋" <liyang.pan@eayun.com>, "李建盛" <jiansheng.li@eayun.com> Cc: "Michal Skrivanek" <mskrivan@redhat.com>, "Scott Herold" <sherold@redhat.com>, "Allon Mureinik" <amureini@redhat.com>, "Federico Simoncelli" <fsimonce@redhat.com>, "Barak Azulay" <bazulay@redhat.com>, "Brian Proffitt" <bproffit@redhat.com>, "Alon Bar-Lev" <alonbl@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
----- Original Message -----
From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "devel" <devel@ovirt.org>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "李建盛" <jiansheng.li@eayun.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> To: "Lucas Vandroux" <lucas.vandroux@eayun.com>, "devel" <devel@ovirt.org>, "潘礼洋" <liyang.pan@eayun.com>, "李建盛" <jiansheng.li@eayun.com> Cc: "Michal Skrivanek" <mskrivan@redhat.com>, "Scott Herold" <sherold@redhat.com>, "Allon Mureinik" <amureini@redhat.com>, "Federico Simoncelli" <fsimonce@redhat.com>, "Barak Azulay" <bazulay@redhat.com>, "Brian Proffitt" <bproffit@redhat.com>, "Alon Bar-Lev" <alonbl@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
----- Original Message -----
From: "Nir Soffer" <nsoffer@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Itamar Heim" <iheim@redhat.com>, "devel" <devel@ovirt.org>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "李建盛" <jiansheng.li@eayun.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@redhat.com>, "Liron Aravot" <laravot@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@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "devel" <devel@ovirt.org>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "李建盛" <jiansheng.li@eayun.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> To: "Lucas Vandroux" <lucas.vandroux@eayun.com>, "devel" <devel@ovirt.org>, "潘礼洋" <liyang.pan@eayun.com>, "李建盛" <jiansheng.li@eayun.com> Cc: "Michal Skrivanek" <mskrivan@redhat.com>, "Scott Herold" <sherold@redhat.com>, "Allon Mureinik" <amureini@redhat.com>, "Federico Simoncelli" <fsimonce@redhat.com>, "Barak Azulay" <bazulay@redhat.com>, "Brian Proffitt" <bproffit@redhat.com>, "Alon Bar-Lev" <alonbl@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
----- Original Message -----
From: "Michal Skrivanek" <mskrivan@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Itamar Heim" <iheim@redhat.com>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "devel" <devel@ovirt.org>, "潘礼洋" <liyang.pan@eayun.com>, "李建盛" <jiansheng.li@eayun.com>, "Scott Herold" <sherold@redhat.com>, "Allon Mureinik" <amureini@redhat.com>, "Federico Simoncelli" <fsimonce@redhat.com>, "Barak Azulay" <bazulay@redhat.com>, "Brian Proffitt" <bproffit@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@redhat.com> wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Lucas Vandroux" <lucas.vandroux@eayun.com>, "devel" <devel@ovirt.org>, "潘礼洋" <liyang.pan@eayun.com>, "李建盛" <jiansheng.li@eayun.com> Cc: "Michal Skrivanek" <mskrivan@redhat.com>, "Scott Herold" <sherold@redhat.com>, "Allon Mureinik" <amureini@redhat.com>, "Federico Simoncelli" <fsimonce@redhat.com>, "Barak Azulay" <bazulay@redhat.com>, "Brian Proffitt" <bproffit@redhat.com>, "Alon Bar-Lev" <alonbl@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.
----- Original Message -----
From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Nir Soffer" <nsoffer@redhat.com> Cc: "devel" <devel@ovirt.org>, "李建盛" <jiansheng.li@eayun.com>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "Liron Aravot" <laravot@redhat.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Itamar Heim" <iheim@redhat.com>, "devel" <devel@ovirt.org>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "李建盛" <jiansheng.li@eayun.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@redhat.com>, "Liron Aravot" <laravot@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@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "devel" <devel@ovirt.org>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "李建盛" <jiansheng.li@eayun.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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
----- Original Message -----
From: "Federico Simoncelli" <fsimonce@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Nir Soffer" <nsoffer@redhat.com>, "devel" <devel@ovirt.org>, "李建盛" <jiansheng.li@eayun.com>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "Liron Aravot" <laravot@redhat.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> To: "Nir Soffer" <nsoffer@redhat.com> Cc: "devel" <devel@ovirt.org>, "李建盛" <jiansheng.li@eayun.com>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "Liron Aravot" <laravot@redhat.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Itamar Heim" <iheim@redhat.com>, "devel" <devel@ovirt.org>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "李建盛" <jiansheng.li@eayun.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@redhat.com>, "Liron Aravot" <laravot@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@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "devel" <devel@ovirt.org>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "李建盛" <jiansheng.li@eayun.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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
----- Original Message -----
From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Federico Simoncelli" <fsimonce@redhat.com> Cc: "Nir Soffer" <nsoffer@redhat.com>, "devel" <devel@ovirt.org>, "李建盛" <jiansheng.li@eayun.com>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "Liron Aravot" <laravot@redhat.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Nir Soffer" <nsoffer@redhat.com>, "devel" <devel@ovirt.org>, "李建盛" <jiansheng.li@eayun.com>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "Liron Aravot" <laravot@redhat.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> To: "Nir Soffer" <nsoffer@redhat.com> Cc: "devel" <devel@ovirt.org>, "李建盛" <jiansheng.li@eayun.com>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "Liron Aravot" <laravot@redhat.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Itamar Heim" <iheim@redhat.com>, "devel" <devel@ovirt.org>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "李建盛" <jiansheng.li@eayun.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@redhat.com>, "Liron Aravot" <laravot@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@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "devel" <devel@ovirt.org>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "李建盛" <jiansheng.li@eayun.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On 12/15/2014 07:33 PM, Federico Simoncelli wrote:
----- Original Message -----
From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Federico Simoncelli" <fsimonce@redhat.com> Cc: "Nir Soffer" <nsoffer@redhat.com>, "devel" <devel@ovirt.org>, "李建盛" <jiansheng.li@eayun.com>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "Liron Aravot" <laravot@redhat.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Nir Soffer" <nsoffer@redhat.com>, "devel" <devel@ovirt.org>, "李建盛" <jiansheng.li@eayun.com>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "Liron Aravot" <laravot@redhat.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> To: "Nir Soffer" <nsoffer@redhat.com> Cc: "devel" <devel@ovirt.org>, "李建盛" <jiansheng.li@eayun.com>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "Liron Aravot" <laravot@redhat.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Itamar Heim" <iheim@redhat.com>, "devel" <devel@ovirt.org>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "李建盛" <jiansheng.li@eayun.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@redhat.com>, "Liron Aravot" <laravot@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@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "devel" <devel@ovirt.org>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "李建盛" <jiansheng.li@eayun.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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.
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Federico Simoncelli" <fsimonce@redhat.com>, "Alon Bar-Lev" <alonbl@redhat.com> Cc: "devel" <devel@ovirt.org>, "李建盛" <jiansheng.li@eayun.com>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "Liron Aravot" <laravot@redhat.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> To: "Federico Simoncelli" <fsimonce@redhat.com> Cc: "Nir Soffer" <nsoffer@redhat.com>, "devel" <devel@ovirt.org>, "李建盛" <jiansheng.li@eayun.com>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "Liron Aravot" <laravot@redhat.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Nir Soffer" <nsoffer@redhat.com>, "devel" <devel@ovirt.org>, "李建盛" <jiansheng.li@eayun.com>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "Liron Aravot" <laravot@redhat.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> To: "Nir Soffer" <nsoffer@redhat.com> Cc: "devel" <devel@ovirt.org>, "李建盛" <jiansheng.li@eayun.com>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "Liron Aravot" <laravot@redhat.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Itamar Heim" <iheim@redhat.com>, "devel" <devel@ovirt.org>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "李建盛" <jiansheng.li@eayun.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@redhat.com>, "Liron Aravot" <laravot@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@redhat.com> > To: "Itamar Heim" <iheim@redhat.com> > Cc: "devel" <devel@ovirt.org>, "Lucas Vandroux" > <lucas.vandroux@eayun.com>, > "李建盛" <jiansheng.li@eayun.com>, "潘礼洋" > <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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
On 12/16/2014 12:27 AM, Federico Simoncelli wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Federico Simoncelli" <fsimonce@redhat.com>, "Alon Bar-Lev" <alonbl@redhat.com> Cc: "devel" <devel@ovirt.org>, "李建盛" <jiansheng.li@eayun.com>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "Liron Aravot" <laravot@redhat.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> To: "Federico Simoncelli" <fsimonce@redhat.com> Cc: "Nir Soffer" <nsoffer@redhat.com>, "devel" <devel@ovirt.org>, "李建盛" <jiansheng.li@eayun.com>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "Liron Aravot" <laravot@redhat.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Nir Soffer" <nsoffer@redhat.com>, "devel" <devel@ovirt.org>, "李建盛" <jiansheng.li@eayun.com>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "Liron Aravot" <laravot@redhat.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> To: "Nir Soffer" <nsoffer@redhat.com> Cc: "devel" <devel@ovirt.org>, "李建盛" <jiansheng.li@eayun.com>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "Liron Aravot" <laravot@redhat.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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@redhat.com> > To: "Alon Bar-Lev" <alonbl@redhat.com> > Cc: "Itamar Heim" <iheim@redhat.com>, "devel" <devel@ovirt.org>, "Lucas > Vandroux" <lucas.vandroux@eayun.com>, "李建盛" > <jiansheng.li@eayun.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal > Skrivanek" > <mskrivan@redhat.com>, "Liron Aravot" > <laravot@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@redhat.com> >> To: "Itamar Heim" <iheim@redhat.com> >> Cc: "devel" <devel@ovirt.org>, "Lucas Vandroux" >> <lucas.vandroux@eayun.com>, >> "李建盛" <jiansheng.li@eayun.com>, "潘礼洋" >> <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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?
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Federico Simoncelli" <fsimonce@redhat.com> Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "devel" <devel@ovirt.org>, "李建盛" <jiansheng.li@eayun.com>, "Lucas Vandroux" <lucas.vandroux@eayun.com>, "Liron Aravot" <laravot@redhat.com>, "潘礼洋" <liyang.pan@eayun.com>, "Michal Skrivanek" <mskrivan@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
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
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
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--
participants (7)
-
Alon Bar-Lev -
Federico Simoncelli -
Itamar Heim -
Keith Robertson -
Lucas Vandroux -
Michal Skrivanek -
Nir Soffer