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?