----- Original Message ----- > From: "Itamar Heim" <ih...@redhat.com> > To: "Federico Simoncelli" <fsimo...@redhat.com>, "Alon Bar-Lev" > <alo...@redhat.com> > Cc: "devel" <devel@ovirt.org>, "李建盛" <jiansheng...@eayun.com>, "Lucas > Vandroux" <lucas.vandr...@eayun.com>, "Liron > Aravot" <lara...@redhat.com>, "潘礼洋" <liyang....@eayun.com>, "Michal > Skrivanek" <mskri...@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" <alo...@redhat.com> > >> To: "Federico Simoncelli" <fsimo...@redhat.com> > >> Cc: "Nir Soffer" <nsof...@redhat.com>, "devel" <devel@ovirt.org>, "李建盛" > >> <jiansheng...@eayun.com>, "Lucas Vandroux" > >> <lucas.vandr...@eayun.com>, "Liron Aravot" <lara...@redhat.com>, "潘礼洋" > >> <liyang....@eayun.com>, "Michal Skrivanek" > >> <mskri...@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" <fsimo...@redhat.com> > >>> To: "Alon Bar-Lev" <alo...@redhat.com> > >>> Cc: "Nir Soffer" <nsof...@redhat.com>, "devel" <devel@ovirt.org>, "李建盛" > >>> <jiansheng...@eayun.com>, "Lucas Vandroux" > >>> <lucas.vandr...@eayun.com>, "Liron Aravot" <lara...@redhat.com>, "潘礼洋" > >>> <liyang....@eayun.com>, "Michal Skrivanek" > >>> <mskri...@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" <alo...@redhat.com> > >>>> To: "Nir Soffer" <nsof...@redhat.com> > >>>> Cc: "devel" <devel@ovirt.org>, "李建盛" <jiansheng...@eayun.com>, "Lucas > >>>> Vandroux" <lucas.vandr...@eayun.com>, "Liron > >>>> Aravot" <lara...@redhat.com>, "潘礼洋" <liyang....@eayun.com>, "Michal > >>>> Skrivanek" <mskri...@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" <nsof...@redhat.com> > >>>>> To: "Alon Bar-Lev" <alo...@redhat.com> > >>>>> Cc: "Itamar Heim" <ih...@redhat.com>, "devel" <devel@ovirt.org>, "Lucas > >>>>> Vandroux" <lucas.vandr...@eayun.com>, "李建盛" > >>>>> <jiansheng...@eayun.com>, "潘礼洋" <liyang....@eayun.com>, "Michal > >>>>> Skrivanek" > >>>>> <mskri...@redhat.com>, "Liron Aravot" > >>>>> <lara...@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" <alo...@redhat.com> > >>>>>> To: "Itamar Heim" <ih...@redhat.com> > >>>>>> Cc: "devel" <devel@ovirt.org>, "Lucas Vandroux" > >>>>>> <lucas.vandr...@eayun.com>, > >>>>>> "李建盛" <jiansheng...@eayun.com>, "潘礼洋" > >>>>>> <liyang....@eayun.com>, "Michal Skrivanek" <mskri...@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 _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel