Re: [Gluster-devel] Default behavior of remove brick op
On 18/03/2014, at 10:50 AM, Lalatendu Mohanty wrote: > On 03/18/2014 04:10 PM, Kaushal M wrote: >> IMO, its best if we just remove the default action instead of changing >> its meaning. It is best if force the user to provide an operation for >> the remove-brick command. This way, users using scripts will know that >> something has changed when the script breaks. It is a simple fix if >> the users want to original behavior back, just add commit force as the >> operation. >> >> If we change the default to start, scripts would not break and users >> wouldn't be notified. They'll continue running the script believing >> that the bricks have been forcefully removed, where as it wouldn't be >> the case. This could lead to further problems. >> >> Regarding the deprecation, I suggest we add the deprecation message to >> 3.5 before it ships. We will not be breaking any of the assumed >> functionality for this release, and can safely do the actual change in >> 3.6. > +1 > >> tl;dr, Require an explicit operation for the remove-brick command and >> add the deprecation message to 3.5. Atin has posted a patch for review here, if you guys (and anyone else) has the time: http://review.gluster.org/#/c/7292/ If we can get this done soon + cherry picked into release-3.5 branch, we can make it for 3.5.0. :) + Justin -- Open Source and Standards @ Red Hat twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Default behavior of remove brick op
On 03/18/2014 04:25 PM, Ravishankar N wrote: > On 03/18/2014 04:10 PM, Kaushal M wrote: >> IMO, its best if we just remove the default action instead of changing >> its meaning. It is best if force the user to provide an operation for >> the remove-brick command. This way, users using scripts will know that >> something has changed when the script breaks. It is a simple fix if >> the users want to original behavior back, just add commit force as the >> operation. >> >> If we change the default to start, scripts would not break and users >> wouldn't be notified. They'll continue running the script believing >> that the bricks have been forcefully removed, where as it wouldn't be >> the case. This could lead to further problems. >> >> Regarding the deprecation, I suggest we add the deprecation message to >> 3.5 before it ships. We will not be breaking any of the assumed >> functionality for this release, and can safely do the actual change in >> 3.6. > Speaking of changes, there are other suggestions and improvements [1] > for remove-brick command, including a new 'commit force' option. > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1046568 > > -Ravi Ravi, I think we can work on this particular bug on a separate thread. However thanks for letting us know about it. --Atin >> tl;dr, Require an explicit operation for the remove-brick command and >> add the deprecation message to 3.5. >> >> ~kaushal >> >> On Tue, Mar 18, 2014 at 3:46 PM, Justin Clift wrote: >>> On 18/03/2014, at 10:11 AM, Atin Mukherjee wrote: Hello gluster-devel list, The current implementation of remove brick op has its default behaviour as "force" which leads to data loss when remove brick is executed with out any explicit argument. (BZ - 1046284) I have a question to the community about whether we should make the default behaviour as "start" or should we only allow explicit arguments to be provided in remove brick command to proceed the operation or block it with error message. I feel the first approach is better as most of the other commands also have some default behaviour without any explicit options, however would appreciate community's opinion about it. >>> Personally, I'm a fan of not letting simple mistakes cause >>> data loss. So I feel we should change the default behaviour... >>> but do so with a proper period of notice, so it's not "sudden" >>> >>> eg message in CLI + on website + in docs >>> >>> Similar to how deprecation notices are done, but warning of >>> the change in behaviour >>> >>> The downside is this could potentially break existing scripts, >>> and people will have to be aware of the change. Thus the warning >>> + long grace period. >>> >>> + Justin >>> >>> -- >>> Open Source and Standards @ Red Hat >>> >>> twitter.com/realjustinclift >>> >>> >>> ___ >>> Gluster-devel mailing list >>> Gluster-devel@nongnu.org >>> https://lists.nongnu.org/mailman/listinfo/gluster-devel >> ___ >> Gluster-devel mailing list >> Gluster-devel@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/gluster-devel > > > ___ > Gluster-devel mailing list > Gluster-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Default behavior of remove brick op
On 03/18/2014 04:10 PM, Kaushal M wrote: IMO, its best if we just remove the default action instead of changing its meaning. It is best if force the user to provide an operation for the remove-brick command. This way, users using scripts will know that something has changed when the script breaks. It is a simple fix if the users want to original behavior back, just add commit force as the operation. If we change the default to start, scripts would not break and users wouldn't be notified. They'll continue running the script believing that the bricks have been forcefully removed, where as it wouldn't be the case. This could lead to further problems. Regarding the deprecation, I suggest we add the deprecation message to 3.5 before it ships. We will not be breaking any of the assumed functionality for this release, and can safely do the actual change in 3.6. Speaking of changes, there are other suggestions and improvements [1] for remove-brick command, including a new 'commit force' option. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1046568 -Ravi tl;dr, Require an explicit operation for the remove-brick command and add the deprecation message to 3.5. ~kaushal On Tue, Mar 18, 2014 at 3:46 PM, Justin Clift wrote: On 18/03/2014, at 10:11 AM, Atin Mukherjee wrote: Hello gluster-devel list, The current implementation of remove brick op has its default behaviour as "force" which leads to data loss when remove brick is executed with out any explicit argument. (BZ - 1046284) I have a question to the community about whether we should make the default behaviour as "start" or should we only allow explicit arguments to be provided in remove brick command to proceed the operation or block it with error message. I feel the first approach is better as most of the other commands also have some default behaviour without any explicit options, however would appreciate community's opinion about it. Personally, I'm a fan of not letting simple mistakes cause data loss. So I feel we should change the default behaviour... but do so with a proper period of notice, so it's not "sudden" eg message in CLI + on website + in docs Similar to how deprecation notices are done, but warning of the change in behaviour The downside is this could potentially break existing scripts, and people will have to be aware of the change. Thus the warning + long grace period. + Justin -- Open Source and Standards @ Red Hat twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Default behavior of remove brick op
On 03/18/2014 04:10 PM, Kaushal M wrote: IMO, its best if we just remove the default action instead of changing its meaning. It is best if force the user to provide an operation for the remove-brick command. This way, users using scripts will know that something has changed when the script breaks. It is a simple fix if the users want to original behavior back, just add commit force as the operation. If we change the default to start, scripts would not break and users wouldn't be notified. They'll continue running the script believing that the bricks have been forcefully removed, where as it wouldn't be the case. This could lead to further problems. Regarding the deprecation, I suggest we add the deprecation message to 3.5 before it ships. We will not be breaking any of the assumed functionality for this release, and can safely do the actual change in 3.6. +1 tl;dr, Require an explicit operation for the remove-brick command and add the deprecation message to 3.5. ~kaushal On Tue, Mar 18, 2014 at 3:46 PM, Justin Clift wrote: On 18/03/2014, at 10:11 AM, Atin Mukherjee wrote: Hello gluster-devel list, The current implementation of remove brick op has its default behaviour as "force" which leads to data loss when remove brick is executed with out any explicit argument. (BZ - 1046284) I have a question to the community about whether we should make the default behaviour as "start" or should we only allow explicit arguments to be provided in remove brick command to proceed the operation or block it with error message. I feel the first approach is better as most of the other commands also have some default behaviour without any explicit options, however would appreciate community's opinion about it. Personally, I'm a fan of not letting simple mistakes cause data loss. So I feel we should change the default behaviour... but do so with a proper period of notice, so it's not "sudden" eg message in CLI + on website + in docs Similar to how deprecation notices are done, but warning of the change in behaviour The downside is this could potentially break existing scripts, and people will have to be aware of the change. Thus the warning + long grace period. + Justin -- Open Source and Standards @ Red Hat twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Default behavior of remove brick op
On 18/03/2014, at 10:40 AM, Kaushal M wrote: > IMO, its best if we just remove the default action instead of changing > its meaning. It is best if force the user to provide an operation for > the remove-brick command. This way, users using scripts will know that > something has changed when the script breaks. It is a simple fix if > the users want to original behavior back, just add commit force as the > operation. > > If we change the default to start, scripts would not break and users > wouldn't be notified. They'll continue running the script believing > that the bricks have been forcefully removed, where as it wouldn't be > the case. This could lead to further problems. > > Regarding the deprecation, I suggest we add the deprecation message to > 3.5 before it ships. We will not be breaking any of the assumed > functionality for this release, and can safely do the actual change in > 3.6. > > tl;dr, Require an explicit operation for the remove-brick command and > add the deprecation message to 3.5. +1 Sounds good to me. :) + Justin -- Open Source and Standards @ Red Hat twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Default behavior of remove brick op
IMO, its best if we just remove the default action instead of changing its meaning. It is best if force the user to provide an operation for the remove-brick command. This way, users using scripts will know that something has changed when the script breaks. It is a simple fix if the users want to original behavior back, just add commit force as the operation. If we change the default to start, scripts would not break and users wouldn't be notified. They'll continue running the script believing that the bricks have been forcefully removed, where as it wouldn't be the case. This could lead to further problems. Regarding the deprecation, I suggest we add the deprecation message to 3.5 before it ships. We will not be breaking any of the assumed functionality for this release, and can safely do the actual change in 3.6. tl;dr, Require an explicit operation for the remove-brick command and add the deprecation message to 3.5. ~kaushal On Tue, Mar 18, 2014 at 3:46 PM, Justin Clift wrote: > On 18/03/2014, at 10:11 AM, Atin Mukherjee wrote: >> Hello gluster-devel list, >> >> The current implementation of remove brick op has its default behaviour as >> "force" which leads to data loss when remove brick is executed with out any >> explicit argument. (BZ - 1046284) >> I have a question to the community about whether we should make the default >> behaviour as "start" or should we only allow explicit arguments to be >> provided in remove brick command to proceed the operation or block it with >> error message. >> I feel the first approach is better as most of the other commands also have >> some default behaviour without any explicit options, however would >> appreciate community's opinion about it. > > Personally, I'm a fan of not letting simple mistakes cause > data loss. So I feel we should change the default behaviour... > but do so with a proper period of notice, so it's not "sudden" > > eg message in CLI + on website + in docs > > Similar to how deprecation notices are done, but warning of > the change in behaviour > > The downside is this could potentially break existing scripts, > and people will have to be aware of the change. Thus the warning > + long grace period. > > + Justin > > -- > Open Source and Standards @ Red Hat > > twitter.com/realjustinclift > > > ___ > Gluster-devel mailing list > Gluster-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Default behavior of remove brick op
On 18/03/2014, at 10:11 AM, Atin Mukherjee wrote: > Hello gluster-devel list, > > The current implementation of remove brick op has its default behaviour as > "force" which leads to data loss when remove brick is executed with out any > explicit argument. (BZ - 1046284) > I have a question to the community about whether we should make the default > behaviour as "start" or should we only allow explicit arguments to be > provided in remove brick command to proceed the operation or block it with > error message. > I feel the first approach is better as most of the other commands also have > some default behaviour without any explicit options, however would appreciate > community's opinion about it. Personally, I'm a fan of not letting simple mistakes cause data loss. So I feel we should change the default behaviour... but do so with a proper period of notice, so it's not "sudden" eg message in CLI + on website + in docs Similar to how deprecation notices are done, but warning of the change in behaviour The downside is this could potentially break existing scripts, and people will have to be aware of the change. Thus the warning + long grace period. + Justin -- Open Source and Standards @ Red Hat twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Default behavior of remove brick op
Ohh my bad, it was by mistake !! Thanks Justin. Hello gluster-devel list, The current implementation of remove brick op has its default behaviour as "force" which leads to data loss when remove brick is executed with out any explicit argument. (BZ - 1046284) I have a question to the community about whether we should make the default behaviour as "start" or should we only allow explicit arguments to be provided in remove brick command to proceed the operation or block it with error message. I feel the first approach is better as most of the other commands also have some default behaviour without any explicit options, however would appreciate community's opinion about it. Regards, Atin - Original Message - From: "Justin Clift" To: "Atin Mukherjee" Cc: gluster-devel-ow...@nongnu.org Sent: Tuesday, March 18, 2014 3:16:58 PM Subject: Re: Default behavior of remove brick op Hi Atin, Wrong email address. ;) You'll be wanting to send to gluster-devel, not gluster-devel-owner. :) Regards and best wishes, Justin Clift On 18/03/2014, at 9:36 AM, Atin Mukherjee wrote: > Hi List, > > The current implementation of remove brick op has its default behaviour as > "force" which leads to data loss when remove brick is executed with out any > explicit argument. (BZ - 1046284) > I have a question to the community about whether we should make the default > behaviour as "start" or should we only allow explicit arguments to be > provided in remove brick command to proceed the operation or block it with > error message. > I feel the first approach is better as most of the other commands also have > some default behaviour without any explicit options, however would appreciate > community's opinion about it. > > Regards, > Atin -- Open Source and Standards @ Red Hat twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
