Re: [Gluster-devel] Default behavior of remove brick op

[Ravishankar N]

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 <address@hidden> 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
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/gluster-devel
> _______________________________________________
> Gluster-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/gluster-devel