Re: [Engine-devel] REST-API: Problem with additional DELETE action at collection level
----- Original Message -----
From: "Shubhendu Tripathi" <shtripat(a)redhat.com>
To: "engine-devel" <engine-devel(a)ovirt.org>, "Michael
Pasternak" <mpastern(a)redhat.com>, oliel(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel