[Gluster-devel] Default behavior of remove brick op

[Kaushal M]

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 <justin at gluster.org> 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 at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel