[ovirt-devel] UI Plugin to Upload ISO Files

[Federico Simoncelli]

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Federico Simoncelli" <fsimonce at redhat.com>, "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "devel" <devel at ovirt.org>, "李建盛" <jiansheng.li at eayun.com>, "Lucas Vandroux" <lucas.vandroux at eayun.com>, "Liron
> Aravot" <laravot at redhat.com>, "潘礼洋" <liyang.pan at eayun.com>, "Michal Skrivanek" <mskrivan at 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 at redhat.com>
> >> To: "Federico Simoncelli" <fsimonce at redhat.com>
> >> Cc: "Nir Soffer" <nsoffer at redhat.com>, "devel" <devel at ovirt.org>, "李建盛"
> >> <jiansheng.li at eayun.com>, "Lucas Vandroux"
> >> <lucas.vandroux at eayun.com>, "Liron Aravot" <laravot at redhat.com>, "潘礼洋"
> >> <liyang.pan at eayun.com>, "Michal Skrivanek"
> >> <mskrivan at 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 at redhat.com>
> >>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>> Cc: "Nir Soffer" <nsoffer at redhat.com>, "devel" <devel at ovirt.org>, "李建盛"
> >>> <jiansheng.li at eayun.com>, "Lucas Vandroux"
> >>> <lucas.vandroux at eayun.com>, "Liron Aravot" <laravot at redhat.com>, "潘礼洋"
> >>> <liyang.pan at eayun.com>, "Michal Skrivanek"
> >>> <mskrivan at 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 at redhat.com>
> >>>> To: "Nir Soffer" <nsoffer at redhat.com>
> >>>> Cc: "devel" <devel at ovirt.org>, "李建盛" <jiansheng.li at eayun.com>, "Lucas
> >>>> Vandroux" <lucas.vandroux at eayun.com>, "Liron
> >>>> Aravot" <laravot at redhat.com>, "潘礼洋" <liyang.pan at eayun.com>, "Michal
> >>>> Skrivanek" <mskrivan at 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 at redhat.com>
> >>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
> >>>>> Cc: "Itamar Heim" <iheim at redhat.com>, "devel" <devel at ovirt.org>, "Lucas
> >>>>> Vandroux" <lucas.vandroux at eayun.com>, "李建盛"
> >>>>> <jiansheng.li at eayun.com>, "潘礼洋" <liyang.pan at eayun.com>, "Michal
> >>>>> Skrivanek"
> >>>>> <mskrivan at redhat.com>, "Liron Aravot"
> >>>>> <laravot at 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 at redhat.com>
> >>>>>> To: "Itamar Heim" <iheim at redhat.com>
> >>>>>> Cc: "devel" <devel at ovirt.org>, "Lucas Vandroux"
> >>>>>> <lucas.vandroux at eayun.com>,
> >>>>>> "李建盛" <jiansheng.li at eayun.com>, "潘礼洋"
> >>>>>> <liyang.pan at eayun.com>, "Michal Skrivanek" <mskrivan at 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