[Gluster-devel] Default behavior of remove brick op

Atin Mukherjee amukherj at redhat.com
Tue Mar 18 12:05:55 UTC 2014



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




More information about the Gluster-devel mailing list