* Itamar Heim <iheim(a)redhat.com> [2012-09-10 11:33]:
On 09/10/2012 07:22 PM, Ryan Harper wrote:
>* Itamar Heim <iheim(a)redhat.com> [2012-09-10 11:20]:
>>On 09/10/2012 06:34 PM, Ryan Harper wrote:
>>>* Itamar Heim <iheim(a)redhat.com> [2012-09-10 10:08]:
>>>>On 09/10/2012 05:45 PM, Ryan Harper wrote:
>>>>>* iheim(a)redhat.com <iheim(a)redhat.com> [2012-09-09 15:39]:
>>>>>>Itamar Heim has posted comments on this change.
>>>>>>
>>>>>>Change subject: Add uploadIso API call for pushing ISOs into an
active iso_domain via pool
>>>>>>......................................................................
>>>>>>
>>>>>>
>>>>>>Patch Set 1:
>>>>>>
>>>>>>how would this work for anyone using vdsm api remotely?
>>>>>
>>>>>The wget method supports remote acquisition.
>>>>
>>>>so how would a remote action would look like exactly?
>>>>say, ovirt engine uploading the image over the api?
>>>>or just a remote user - the wget would happen on vdsm rather than on
>>>>the node? usually when uploading the client has the access to the
>>>>image uploaded and it is passed over the api to the target?
>>>
>>>You confuse me a bit with saying 'vdsm rather than on the node' as
my
>>>understanding is that vdsm *is* on the node.
>>
>>indeed - s/node/client/
>>
>>>
>>>Here's how I see it working, and you can tell me if I've missed
>>>something.
>>>
>>>The uploadIso takes a pool UUID which if Active and has an ISO domain,
>>>the vdsm end-point accepting the uploadIso request will have the iso
>>>domain mounted (whether or not the storage is remote or local) in which
>>>case the wget of the remote ISO write out into isoprefix location.
>>>
>>>
>>
>>
>>which means vdsm needs to access the iso, rather than the client.
>>so the client can't really upload an iso which is accessible to the
>>client this way?
>
>Client pushing in a localfile, no, but I could see about adding that if
>that makes this more useful.
>
>
>
the main use case i see for this is an end user that wants to upload
My main use-case is to work with vdsm directly;
the image. users authenticate and communicate mostly with ovirt
engine, not directly to hosts (they do for spice, and we will remove
that via a proxy as well).
any thoughts on how to solve this use case?
Don't you already have engine-iso-uploader? I did see that some folks
would like an in-gui method to do this, so we could address both
use-cases with the same API call.
In the engine UI case, you have two cases to handle:
1) user specifies an http url where the iso file is located
2) user has access on the client to an iso file she would like to
push into the iso repository
the uploadIso verb handles (1) right now. For (2), I see two ways:
(a) engine could accept the http put from the client and store the iso
temporarily on the engine server, from there push to vdsm via the
uploadIso call. The advantage here would be that the client itself
wouldn't need to authenticate to push data into vdsm.
(b) engine could direct the client to push the iso to vdsm directly.
Could be authenticated much like setVMTicket w.r.t allocating a window
for the client to connect and push data.
I don't see any verbs in VDSM yet where we accept lots of data via push,
so this would be something we need to think about how best to handle.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh(a)us.ibm.com