[Gluster-devel] Default behavior of remove brick op

[Lalatendu Mohanty]

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