Self and Ori had a detailed discussion on the topic.
Points discussed -
1. Ori mentioned that Michael and Ori did not mean to have a separate
DELETE action for the purpose of commit in previous discussions.
2. Ori tried to understand the intention behind the separate commit
command in gluster and suggested that ideally gluster should remember
that a migration of data is started on the set of bricks, and if there
is a delete fired on the same bricks it should perform a commit action
because commit is nothing but a delete action
3. Ori suggested that in an ideal situation APIs needed would be
- start migrate
- stop migrate
- delete bricks
- retain bricks
4. As suggested by Ori, the remove bricks action should internally
decide if there was a data migration, started on the set of bricks. If
so, it should effectively fire a commit for the set of bricks. And if
there was not occurrence of data migration it should behave like a
normal force remove action.
Ori, please add your comments if I have missed out anything here.
Sahina, request your comments on the same.
Thanks and Regards,
Shubhendu
On 11/11/2013 10:30 AM, Shubhendu Tripathi wrote:
On 11/10/2013 11:06 PM, Moti Asayag wrote:
----- Original Message -----
From: "Shubhendu Tripathi" <shtri...@redhat.com>
To: "engine-devel" <engine-devel@ovirt.org>, "Michael Pasternak"
<mpast...@redhat.com>, ol...@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.
Moti, I have introduced another methods remove of DELETE type which
takes Action as input.
I pass list of bricks and force as parameter in the same Action.
Also, I tried marking the old method deprecated and introduced the new
one BUT as mentioned above, after introduction of new DELETE with
Action parameter old one STOPS working.
Is it OK to stop working for a method if its deprecated?? I don't feel
so. Please comment.
<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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
