[Engine-devel] REST-API: Problem with additional DELETE action at collection level

[Moti Asayag]

----- Original Message -----
> From: "Shubhendu Tripathi" <shtripat at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>, "Michael Pasternak" <mpastern at redhat.com>, oliel at redhat.com
> Sent: Friday, November 8, 2013 8:37:30 AM
> Subject: [Engine-devel] REST-API: Problem with additional DELETE action at	collection level
> 
> Hi All,
> 
> There is a DELETE action defined at collection level for Gluster Bricks with
> signature -
> 
> @DELETE
> public Response remove ( GlusterBricks bricks );
> 
> Recently we had needed a commit action to remove migrated bricks.
> After multiple rounds of discussion on introducing a commit action to remove
> migrated bricks we introduced a DELETE action [1] which accepts a boolean
> parameter isForce.
> If the parameter is set to true , forced deletion of bricks happens without
> any data migration.
> And if the parameter is not set or set to false, the deletion is meant for a
> brick on which migration has already taken place.
> 
> To achieve the above functionality we introduced another DELETE action with
> new signature as below and also marked the first action as deprecated -
> 
> @DELETE
> public Response remove ( Action action );
> 
> The problem arises now as the new api works fine for all possible scenarios
> with below input structure -
> 
> <action>
> <force>true/false</force>
> <bricks>
> <brick>
> <name> brick1-name</name>
> <name>brick2-name</name>
> </brick>
> </bricks>
> </action>
> 
> BUT after these change backward compatibility is broken and the old api does
> not work.
> If we try invoking old DELETE with bricks as input parameter as below, it
> still invokes the new api and gives an error saying " Invalid parameter ".
> 

Maybe I've missed it some where, but i wasn't able to find the new 'force' parameter
in the rsdl, and specifically not in optionalArguments list of:

- name: /api/clusters/{cluster:id}/glustervolumes/{glustervolume:id}/bricks|rel=delete

and perhaps the correct approach will be to deprecate this signature and introduce a new
one with the 'force' in the 'mandatoryArguments' section.

> <bricks>
> <brick id="brick1-id"/>
> <brick id="brick2-id"/>
> </bricks>
> 
> Kindly suggest a solution around the same.
> 
> PS: Both the actions are defined at collection level (
> /api/clusters/<cluster-id>/glustervolumes/<volume-id>/bricks )
> 
> [1]: http://gerrit.ovirt.org/#/c/21043/
> 
> Thanks and Regards,
> Shubhendu
> 
> 
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>