11:59 p.m.
This is a multi-part message in MIME format.
--------------050509030900000404030401
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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".
/
//<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
--------------050509030900000404030401
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi All,<br>
<br>
There is a DELETE action defined at collection level for Gluster
Bricks with signature -<br>
<br>
<font color="#3333ff"><i><span
class="kwd">@DELETE<br>
public</span></i><i><span class="pln">
</span></i><i><span
class="typ">Response</span></i><i><span
class="pln"> remove</span></i><i><span
class="pun">(</span></i><i><span
class="typ">GlusterBricks</span></i><i><span
class="pln"> bricks</span></i></font><span
class="pun"><font
color="#3333ff"><i>);</i></font><br>
<br>
Recently we had needed a commit action to remove migrated bricks.
<br>
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.<br>
If the parameter is set to <i>true</i>, forced deletion of bricks
happens without any data migration.<br>
And if the parameter is not set or set to <i>false,</i> the
deletion is meant for a brick on which migration has already taken
place.<br>
<br>
To achieve the above functionality we introduced another DELETE
action with new signature as below and </span><span
class="pun"><span
class="pun"><span class="pun">also marked the first
action as
deprecated</span></span> -<br>
<br>
</span><span class="pun"><font
color="#3333ff"><i><span class="kwd">@DELETE<br>
public</span></i><i><span class="pln">
</span></i><i><span
class="typ">Response</span></i><i><span
class="pln"> remove</span></i><i><span
class="pun">(</span></i><i><span
class="typ">Action</span></i><i><span
class="pln"> action</span></i></font><span
class="pun"><font
color="#3333ff"><i>);</i></font><br>
<br>
The problem arises now as the new api works fine for all
possible scenarios with below input structure -<br>
<font color="#3333ff"><i><br>
</i><i><action></i><i><br>
</i><i>
<force>true/false</force></i><i><br>
</i><i>
<bricks></i><i><br>
</i><i>
<brick></i><i><br>
</i><i>
<name></i><i>brick1-name</name></i><i><br>
</i></font></span></span><span
class="pun"><span class="pun"><font
color="#3333ff"><i><span class="pun"><span
class="pun">
<name>brick2-name</name></span></span></i><i><br>
</i><i>
</brick></i><i><br>
</i><i>
</bricks></i><i><br>
</i><i></action></i></font><br>
<br>
BUT after these change backward compatibility is broken and the
old api does not work.<br>
If we try invoking old DELETE with bricks as input parameter as
below, it still invokes the new api and gives an error saying "<font
color="#ff0000">Invalid parameter</font>".<br>
<font color="#3333ff"><i><br>
</i></font></span></span><font
color="#3333ff"><i><span
class="pun"><span class="pun"><span
class="pun"><span
class="pun"><bricks><br>
<brick
id="brick1-id"/><br>
</span></span></span></span></i></font><span
class="pun"><span
class="pun"><font color="#3333ff"><i><span
class="pun"><span
class="pun"><span class="pun"><span
class="pun"><span
class="pun"><span
class="pun"> <brick
id="brick2-id"/></span></span></span></span><br>
</bricks></span></span></i></font><br>
<br>
Kindly suggest a solution around the same.<br>
<br>
<b>PS:</b> Both the actions are defined at collection level (<font
color="#3333ff"><i>/api/clusters/<cluster-id>/glustervolumes/<volume-id>/bricks</i></font>)<br>
<br>
[1]: <a
href="http://gerrit.ovirt.org/#/c/21043/">http://gerrit.ovir...
<br>
Thanks and Regards,<br>
Shubhendu<br>
<br>
<br>
</span></span>
</body>
</html>
--------------050509030900000404030401--
12:37 a.m.
This is a multi-part message in MIME format.
--------------010703000301070404040104
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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".
/
//<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
--------------010703000301070404040104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi All,<br>
<div class="moz-forward-container"> <br>
There is a DELETE action defined at collection level for Gluster
Bricks with signature -<br>
<br>
<font color="#3333ff"><i><span
class="kwd">@DELETE<br>
public</span></i><i><span class="pln">
</span></i><i><span
class="typ">Response</span></i><i><span
class="pln"> remove</span></i><i><span
class="pun">(</span></i><i><span
class="typ">GlusterBricks</span></i><i><span
class="pln"> bricks</span></i></font><span
class="pun"><font
color="#3333ff"><i>);</i></font><br>
<br>
Recently we had needed a commit action to remove migrated
bricks. <br>
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.<br>
If the parameter is set to <i>true</i>, forced deletion of
bricks happens without any data migration.<br>
And if the parameter is not set or set to <i>false,</i> the
deletion is meant for a brick on which migration has already
taken place.<br>
<br>
To achieve the above functionality we introduced another DELETE
action with new signature as below and </span><span
class="pun"><span
class="pun"><span class="pun">also marked the first
action as
deprecated</span></span> -<br>
<br>
</span><span class="pun"><font
color="#3333ff"><i><span
class="kwd">@DELETE<br>
public</span></i><i><span class="pln">
</span></i><i><span
class="typ">Response</span></i><i><span
class="pln">
remove</span></i><i><span
class="pun">(</span></i><i><span
class="typ">Action</span></i><i><span
class="pln"> action</span></i></font><span
class="pun"><font
color="#3333ff"><i>);</i></font><br>
<br>
The problem arises now as the new api works fine for all
possible scenarios with below input structure -<br>
<font color="#3333ff"><i><br>
</i><i><action></i><i><br>
</i><i>
<force>true/false</force></i><i><br>
</i><i>
<bricks></i><i><br>
</i><i>
<brick></i><i><br>
</i><i>
<name></i><i>brick1-name</name></i><i><br>
</i></font></span></span><span
class="pun"><span class="pun"><font
color="#3333ff"><i><span
class="pun"><span class="pun">
<name>brick2-name</name></span></span></i><i><br>
</i><i>
</brick></i><i><br>
</i><i>
</bricks></i><i><br>
</i><i></action></i></font><br>
<br>
BUT after these change backward compatibility is broken and
the old api does not work.<br>
If we try invoking old DELETE with bricks as input parameter
as below, it still invokes the new api and gives an error
saying "<font color="#ff0000">Invalid
parameter</font>".<br>
<font color="#3333ff"><i><br>
</i></font></span></span><font
color="#3333ff"><i><span
class="pun"><span class="pun"><span
class="pun"><span
class="pun"><bricks><br>
<brick
id="brick1-id"/><br>
</span></span></span></span></i></font><span
class="pun"><span
class="pun"><font color="#3333ff"><i><span
class="pun"><span
class="pun"><span class="pun"><span
class="pun"><span
class="pun"><span
class="pun"> <brick
id="brick2-id"/></span></span></span></span><br>
</bricks></span></span></i></font><br>
<br>
Kindly suggest a solution around the same.<br>
<br>
<b>PS:</b> Both the actions are defined at collection level
(<font
color="#3333ff"><i>/api/clusters/<cluster-id>/glustervolumes/<volume-id>/bricks</i></font>)<br>
<br>
[1]: <a moz-do-not-send="true"
href="http://gerrit.ovirt.org/#/c/21043/">http://gerrit.ovir...
<br>
Thanks and Regards,<br>
Shubhendu<br>
<br>
<br>
</span></span> <br>
</div>
<br>
</body>
</html>
--------------010703000301070404040104--
11:36 a.m.
New subject: [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
11 p.m.
New subject: [Engine-devel] REST-API: Problem with additional DELETE action at collection level
On 11/10/2013 11:06 PM, Moti Asayag wrote:
----- 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.
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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
4 a.m.
New subject: [Engine-devel] REST-API: Problem with additional DELETE action at collection level
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" <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.
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(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
4:38 a.m.
New subject: [Engine-devel] REST-API: Problem with additional DELETE action at collection level
----- Original Message -----
From: "Shubhendu Tripathi" <shtripat(a)redhat.com>
To: oliel(a)redhat.com, "Michael Pasternak" <mpastern(a)redhat.com>,
"Sahina Bose" <sabose(a)redhat.com>
Cc: "Dusmant Pati" <dpati(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>
Sent: Monday, November 11, 2013 12:00:34 PM
Subject: Re: [Engine-devel] REST-API: Problem with additional DELETE action at collection
level
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.
That's right - no need for a new delete signature; existing signatures are enough.
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.
I agree with what you wrote, let me sort of say it again in my words:
I don't like requiring two consecutive commands from the API user, to perform migrate.
If the user only does 'migrate', and doesn't do the second step, we are in a
state of
corruption. But Shubhendu explained to me that there's no way around this; the
administrator *must* take a look and decide; it is simply not possible to make this
decision in advance. So I accepted this heavy-heartedly.
Then we were left with the decision of how to model this two step operation. I tried to
look at it from the point of view of the user; what would be the simplest way to 'tell
him
the story?'
- If you want to migrate a brick, run 'migrate' on it.
- If you want to stop migration of the brick, run 'stopMigrate' on it.
- If you want to resume the migration of the brick, simply run 'migrate' on it
again.
After migration is done:
- if you want to remove the brick, DELETE it (regular delete).
- if you want to keep using the brick, run 'reactivate' on it.
And that's the whole story.
The advantages are:
* In simple English, not bound to Gluster terms, the administrator has to decide whether
to
get rid of the brick, remove it, when migration is done. So what would be more natural
than
to delete it? It makes sense, and there's no need for a new 'action'. On the
Gluster side,
if user tried to delete a brick which is undergoing migration - simply don't allow it.
This
is something you have to do anyway; a user might try to delete a brick which is
undergoing
migration and you have to stop him from doing so. So 0 extra work here.
* Instead of stopMigrate meaning two different things in two different contexts, we now
have stopMigration mean exactly what its name suggests: it stops the migration, and
'reactive'
mean exactly what it suggests - mark this brick as active again, allow it to be used.
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" <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.
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(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
5:03 a.m.
New subject: [Engine-devel] REST-API: Problem with additional DELETE action at collection level
On 11/11/2013 04:08 PM, Ori Liel wrote:
> ----- Original Message -----
> From: "Shubhendu Tripathi" <shtripat(a)redhat.com>
> To: oliel(a)redhat.com, "Michael Pasternak" <mpastern(a)redhat.com>,
"Sahina Bose" <sabose(a)redhat.com>
> Cc: "Dusmant Pati" <dpati(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>
> Sent: Monday, November 11, 2013 12:00:34 PM
> Subject: Re: [Engine-devel] REST-API: Problem with additional DELETE action
at collection level
>
> 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.
That's right - no need for a new delete signature; existing signatures are enough.
> 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.
I agree with what you wrote, let me sort of say it again in my words:
I don't like requiring two consecutive commands from the API user, to perform
migrate.
If the user only does 'migrate', and doesn't do the second step, we are in a
state of
corruption. But Shubhendu explained to me that there's no way around this; the
administrator *must* take a look and decide; it is simply not possible to make this
decision in advance. So I accepted this heavy-heartedly.
Then we were left with the decision of how to model this two step operation. I tried to
look at it from the point of view of the user; what would be the simplest way to
'tell him
the story?'
- If you want to migrate a brick, run 'migrate' on it.
- If you want to stop migration of the brick, run 'stopMigrate' on it.
- If you want to resume the migration of the brick, simply run 'migrate' on it
again.
After migration is done:
- if you want to remove the brick, DELETE it (regular delete).
- if you want to keep using the brick, run 'reactivate' on it.
And that's the whole story.
The advantages are:
* In simple English, not bound to Gluster terms, the administrator has to decide whether
to
get rid of the brick, remove it, when migration is done. So what would be more natural
than
to delete it? It makes sense, and there's no need for a new 'action'. On the
Gluster side,
if user tried to delete a brick which is undergoing migration - simply don't allow
it. This
is something you have to do anyway; a user might try to delete a brick which is
undergoing
migration and you have to stop him from doing so. So 0 extra work here.
* Instead of stopMigrate meaning two different things in two different contexts, we now
have stopMigration mean exactly what its name suggests: it stops the migration, and
'reactive'
mean exactly what it suggests - mark this brick as active again, allow it to be used.
Thanks Ori for the detailed mail.
So now the final set of APIs are -
- migrate
- stopmigrate
- delete (existing delete to be enabled for commit)
- reactivate
Will go ahead with this and raise the patches accordingly.
Thanks and Regards,
Shubhendu
> 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" <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.
> 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(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
9:47 a.m.
New subject: [Engine-devel] REST-API: Problem with additional DELETE action at collection level
Guys, I apologize, but after considering it some more, I think there's a basic problem
in what I've suggested.
What I described would be great, if there would never be a need to delete a brick during
the process of its
migration, or in other words to force its deletion. But since we must have such an option,
in case migration goes
wrong and we decide to get rid of the brick at all cost, then we must be ablechoose
force=true or force=false.
We've already had this discussion, and the original conclusion was right: this does
require another signature for
DELETE, one which receives an Action object and sets force=true or force=false inside it -
just like what Shubhendu
described that he tried to do in his email. Telling you, Shubhendu, that another signature
is unnecessary was wrong,
took you a step back and waisted of your time. I hope you haven't spent much effort
implementing what we said yet,
as we reached an agreement relatively late in your working day... So my sincere apologies
for that. I am well aware
that as it is a lot of time has been invested in agreeing on the correct API.
I will now revisit your original question, Shubehendu, and soon reply to that, addressing
the technical difficulty
that you encountered.
Ori.
----- Original Message -----
From: "Shubhendu Tripathi" <shtripat(a)redhat.com>
To: "Ori Liel" <oliel(a)redhat.com>
Cc: "Michael Pasternak" <mpastern(a)redhat.com>, "Sahina Bose"
<sabose(a)redhat.com>, "Dusmant Pati" <dpati(a)redhat.com>,
"engine-devel" <engine-devel(a)ovirt.org>
Sent: Monday, November 11, 2013 1:03:53 PM
Subject: Re: [Engine-devel] REST-API: Problem with additional DELETE action at collection
level
On 11/11/2013 04:08 PM, Ori Liel wrote:
> ----- Original Message -----
> From: "Shubhendu Tripathi" <shtripat(a)redhat.com>
> To: oliel(a)redhat.com, "Michael Pasternak" <mpastern(a)redhat.com>,
"Sahina Bose" <sabose(a)redhat.com>
> Cc: "Dusmant Pati" <dpati(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>
> Sent: Monday, November 11, 2013 12:00:34 PM
> Subject: Re: [Engine-devel] REST-API: Problem with additional DELETE action
at collection level
>
> 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.
That's right - no need for a new delete signature; existing signatures are enough.
> 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.
I agree with what you wrote, let me sort of say it again in my words:
I don't like requiring two consecutive commands from the API user, to perform
migrate.
If the user only does 'migrate', and doesn't do the second step, we are in a
state of
corruption. But Shubhendu explained to me that there's no way around this; the
administrator *must* take a look and decide; it is simply not possible to make this
decision in advance. So I accepted this heavy-heartedly.
Then we were left with the decision of how to model this two step operation. I tried to
look at it from the point of view of the user; what would be the simplest way to
'tell him
the story?'
- If you want to migrate a brick, run 'migrate' on it.
- If you want to stop migration of the brick, run 'stopMigrate' on it.
- If you want to resume the migration of the brick, simply run 'migrate' on it
again.
After migration is done:
- if you want to remove the brick, DELETE it (regular delete).
- if you want to keep using the brick, run 'reactivate' on it.
And that's the whole story.
The advantages are:
* In simple English, not bound to Gluster terms, the administrator has to decide whether
to
get rid of the brick, remove it, when migration is done. So what would be more natural
than
to delete it? It makes sense, and there's no need for a new 'action'. On the
Gluster side,
if user tried to delete a brick which is undergoing migration - simply don't allow
it. This
is something you have to do anyway; a user might try to delete a brick which is
undergoing
migration and you have to stop him from doing so. So 0 extra work here.
* Instead of stopMigrate meaning two different things in two different contexts, we now
have stopMigration mean exactly what its name suggests: it stops the migration, and
'reactive'
mean exactly what it suggests - mark this brick as active again, allow it to be used.
Thanks Ori for the detailed mail.
So now the final set of APIs are -
- migrate
- stopmigrate
- delete (existing delete to be enabled for commit)
- reactivate
Will go ahead with this and raise the patches accordingly.
Thanks and Regards,
Shubhendu
> 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" <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.
> 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(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
10:20 a.m.
Shubhendu,
The problem you're describing stems from the fact that BackendGlusterBricksResource
already has an implementation of 'remove' which recieves an object
(GlusterBricks). This creates ambiguity that RestEasy can't resolve: it has no way of
deciding whether to deserialize the XML data into an 'Action' object or into a
'GlusterBricks' object. Within the current limitation of RestEasy, this problem is
unsolvable.
To overcome this, we can take a different approach: pass 'force' as a URL matrix
parameter. In order to see how this is achieved technically, I refer you to
BackendResource.isAsync() method. 'async' is a URL matrix parameter, and this
simple method shows how it's fetched from the URL. Implementing something similar for
force should be easy.
On our side, I will deprecate all current uses of 'force' in the API and move them
all to be URL matrix parameters, so that we'll be aligned with you.
Michael will be here tomorrow, and on Wednesday I'll also be available again, to help
and/or review.
Thanks,
Ori.
----- 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
Cc: "Dusmant Pati" <dpati(a)redhat.com>
Sent: Friday, November 8, 2013 7:59:59 AM
Subject: 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".
/
//<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
3856
days inactive
3859
days old
8 comments
3 participants
participants (3)
-
Moti Asayag -
Ori Liel -
Shubhendu Tripathi