3:17 a.m.
On 2014年08月20日 14:06, Royce Lv wrote:
On 2014年08月20日 03:17, Aline Manera wrote:
>
> On 08/19/2014 04:03 PM, Crístian Viana wrote:
>> On 19-08-2014 13:53, Crístian Viana wrote:
>>> On 19-08-2014 10:49, Aline Manera wrote:
>>>> Just one more comment along the others made by Royce.
>>>>
>>>> Yes - download and upload functionality will be available to all
>>>> pools.
>>>
>>> Ok! So I'll update the RFC to support multiple storage pools and to
>>> use the Tasks API to handle the pause/resume/cancel operations.
>>
>> Well, Aline and I found a problem with this proposal. Currently, the
>> REST API always redirects "POST" requests in a Collection to the
>> function "<colletion-name>_create". In our case, if we send
"POST
>> /storagepools/<pool-name>/storagevolumes/download", that would be
>> redirected to the backend function "storagevolumes_create". There is
>> no way to redirect those requests to different functions (like,
>> ideally, "storagevolumes_download" and
"storagevolumes_upload").
>>
>> So I see two options from here:
>>
>> 1) Use the first API proposed by Aline: "POST
>> /storagepools/<pool-name>/storagevolumes". By looking at the
>> parameters (i.e. whether 'url' starts with "file://" or
>> "[http|ftp]://") we can tell if the operation is download or upload.
>
> We can use "url" for download and "file" for upload.
>
> if "url" in params.keys():
> self.download()
> elif "file" in params.keys():
> self.upload()
>
>>
>> 2) Remodel the control code to support multiple actions when
>> POST'ing to a Collection.
>
> It will not be possible as we expect to have an resource id instead
> of an action name.
> To be able to do it we should treat the action name as a reserved
> name to avoid having a id and action with the same name
>
> # This is a resource named "upload"
> /storagepools/upload
>
> # This is an action upload on storagepools collection
> /storagepools/upload
>
> I strongly suggest to adopt option 1.
> The if/else will not be a big deal as we can do the functions self
> contained for easy maintenance.
>
Yeah, I realize this is an error which actions are always on resource,
not on collection, so if we want to adopt this, the API will be:
POST /storagepools/pool-name/upload {parameter}
I think this would be proper. What do you think?
After a second thought, I think
POST and return resource may be the only
reasonable option.
It returns the volume information (may be future task id).
We need to consider how to make the model part more clean in implementation.
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel