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 <jus...@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@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
