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

----- Original Message ----- > From: "Shubhendu Tripathi" <shtripat(a)redhat.com&gt; > To: "engine-devel" <engine-devel(a)ovirt.org&gt;, "Michael Pasternak" <mpastern(a)redhat.com&gt;, 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 >