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.