Re: [Gluster-devel] [Gluster-users] Proposal to deprecate replace-brick for "distribute only" volumes

[Shyam]

On 03/16/2017 08:59 AM, Joe Julian wrote:

In the last few releases, we have changed replace-brick command such
that it can be called only with "commit force" option. When invoked,
this is what happens to the volume:

a. distribute only volume: the given brick is replaced with a empty
brick with 100% probability of data loss.
b. distribute-replicate: the given brick is replaced with a empty
brick and self heal is triggered. If admin is wise enough to monitor
self heal status before another replace-brick command, data is safe.
c. distribute-disperse: same as above in distribute-replicate

My proposal is to fully deprecate replace-brick command for
"distribute only" volumes. It should print out a error "The right way
to replace brick for distribute only volume is to add brick, wait for
rebalance to complete and remove brick" and return a "-1".


I am responding late, assuming this is still not done or WIP. Correct me 
if I am wrong.


Yes, we need the above. As it really does not make any sense in the way 
the current (replace brick) command is structured to lose a pure 
distribute brick.







It makes sense.
I just don't see any use of add-brick before remove-brick except the
fact that it will
help to keep the overall storage capacity of volume intact .
What is the guarantee that the files on the brick which we want to
replace
would migrate to added brick?

If a brick, which we want to replace, is healthy and we just want to
replace it then perhaps we should provide
a command to copy those files to new brick and then remove the old
brick.


We used to have a command that did just that. It was replace-brick.


This involves some rebalance trickery IMO (if we leverage that to 
replace the brick in a distribute only volume), which we do not have. I 
would suggest a github issue be added for such support, and take in the 
prevention of current replace-brick on distribute only volumes as the 
first priority (for obvious reasons as stated by talur).


Shyam
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Proposal to deprecate replace-brick for "distribute only" volumes

[Joe Julian]

On March 16, 2017 4:17:04 AM PDT, Ashish Pandey <aspan...@redhat.com> wrote:
>
>
>- Original Message -
>
>From: "Atin Mukherjee" <atin.mukherje...@gmail.com> 
>To: "Raghavendra Talur" <rta...@redhat.com>, gluster-devel@gluster.org,
>gluster-us...@gluster.org 
>Sent: Thursday, March 16, 2017 4:22:41 PM 
>Subject: Re: [Gluster-devel] [Gluster-users] Proposal to deprecate
>replace-brick for "distribute only" volumes 
>
>Makes sense. 
>
>On Thu, 16 Mar 2017 at 06:51, Raghavendra Talur < rta...@redhat.com >
>wrote: 
>
>
>Hi, 
>
>In the last few releases, we have changed replace-brick command such 
>that it can be called only with "commit force" option. When invoked, 
>this is what happens to the volume: 
>
>a. distribute only volume: the given brick is replaced with a empty 
>brick with 100% probability of data loss. 
>b. distribute-replicate: the given brick is replaced with a empty 
>brick and self heal is triggered. If admin is wise enough to monitor 
>self heal status before another replace-brick command, data is safe. 
>c. distribute-disperse: same as above in distribute-replicate 
>
>My proposal is to fully deprecate replace-brick command for 
>"distribute only" volumes. It should print out a error "The right way 
>to replace brick for distribute only volume is to add brick, wait for 
>rebalance to complete and remove brick" and return a "-1". 
>
>
>
>
>It makes sense. 
>I just don't see any use of add-brick before remove-brick except the
>fact that it will 
>help to keep the overall storage capacity of volume intact . 
>What is the guarantee that the files on the brick which we want to
>replace 
>would migrate to added brick? 
>
>If a brick, which we want to replace, is healthy and we just want to
>replace it then perhaps we should provide 
>a command to copy those files to new brick and then remove the old
>brick. 

We used to have a command that did just that. It was replace-brick.

>
>
>
>
>Thoughts? 
>
>Thanks, 
>Raghavendra Talur 
>___ 
>Gluster-users mailing list 
>gluster-us...@gluster.org 
>http://lists.gluster.org/mailman/listinfo/gluster-users 
>
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Proposal to deprecate replace-brick for "distribute only" volumes

[Ashish Pandey]

- Original Message -

From: "Atin Mukherjee" <atin.mukherje...@gmail.com> 
To: "Raghavendra Talur" <rta...@redhat.com>, gluster-devel@gluster.org, 
gluster-us...@gluster.org 
Sent: Thursday, March 16, 2017 4:22:41 PM 
Subject: Re: [Gluster-devel] [Gluster-users] Proposal to deprecate 
replace-brick for "distribute only" volumes 

Makes sense. 

On Thu, 16 Mar 2017 at 06:51, Raghavendra Talur < rta...@redhat.com > wrote: 


Hi, 

In the last few releases, we have changed replace-brick command such 
that it can be called only with "commit force" option. When invoked, 
this is what happens to the volume: 

a. distribute only volume: the given brick is replaced with a empty 
brick with 100% probability of data loss. 
b. distribute-replicate: the given brick is replaced with a empty 
brick and self heal is triggered. If admin is wise enough to monitor 
self heal status before another replace-brick command, data is safe. 
c. distribute-disperse: same as above in distribute-replicate 

My proposal is to fully deprecate replace-brick command for 
"distribute only" volumes. It should print out a error "The right way 
to replace brick for distribute only volume is to add brick, wait for 
rebalance to complete and remove brick" and return a "-1". 




It makes sense. 
I just don't see any use of add-brick before remove-brick except the fact that 
it will 
help to keep the overall storage capacity of volume intact . 
What is the guarantee that the files on the brick which we want to replace 
would migrate to added brick? 

If a brick, which we want to replace, is healthy and we just want to replace it 
then perhaps we should provide 
a command to copy those files to new brick and then remove the old brick. 




Thoughts? 

Thanks, 
Raghavendra Talur 
___ 
Gluster-users mailing list 
gluster-us...@gluster.org 
http://lists.gluster.org/mailman/listinfo/gluster-users 



-- 
--Atin 

___ 
Gluster-devel mailing list 
Gluster-devel@gluster.org 
http://lists.gluster.org/mailman/listinfo/gluster-devel 

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Proposal to deprecate replace-brick for "distribute only" volumes

[Atin Mukherjee]

Makes sense.

On Thu, 16 Mar 2017 at 06:51, Raghavendra Talur  wrote:

> Hi,
>
> In the last few releases, we have changed replace-brick command such
> that it can be called only with "commit force" option. When invoked,
> this is what happens to the volume:
>
> a. distribute only volume: the given brick is replaced with a empty
> brick with 100% probability of data loss.
> b. distribute-replicate: the given brick is replaced with a empty
> brick and self heal is triggered. If admin is wise enough to monitor
> self heal status before another replace-brick command, data is safe.
> c. distribute-disperse: same as above in distribute-replicate
>
> My proposal is to fully deprecate replace-brick command for
> "distribute only" volumes. It should print out a error "The right way
> to replace brick for distribute only volume is to add brick, wait for
> rebalance to complete and remove brick" and return a "-1".
>
> Thoughts?
>
> Thanks,
> Raghavendra Talur
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users
>
-- 
--Atin
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel