[ovirt-devel] UI Plugin to Upload ISO Files

[Itamar Heim]

On 12/16/2014 12:27 AM, Federico Simoncelli wrote:
>
>
> ----- 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.
>

I thought 'upload' is vdsm pushing to say, glance. not accepting from 
engine?