[Gluster-devel] Need inputs for command deprecation output

[Niels de Vos]

On Fri, May 16, 2014 at 05:35:06PM +0530, Vijay Bellur wrote:
> On 05/16/2014 07:23 AM, Pranith Kumar Karampuri wrote:
> >
> >
> >----- Original Message -----
> >>From: "Ravishankar N" <ravishankar at redhat.com>
> >>To: "Pranith Kumar Karampuri" <pkarampu at redhat.com>, "Gluster Devel" <gluster-devel at gluster.org>
> >>Sent: Friday, May 16, 2014 7:15:58 AM
> >>Subject: Re: [Gluster-devel] Need inputs for command deprecation output
> >>
> >>On 05/16/2014 06:25 AM, Pranith Kumar Karampuri wrote:
> >>>Hi,
> >>>     As part of changing behaviour of 'volume heal' commands. I want the
> >>>     commands to show the following output. Any feedback in making them
> >>>     better would be awesome :-).
> >>>
> >>>root at pranithk-laptop - ~
> >>>06:20:10 :) ⚡ gluster volume heal r2 info healed
> >>>This command has been deprecated
> >>>
> >>>root at pranithk-laptop - ~
> >>>06:20:13 :( ⚡ gluster volume heal r2 info heal-failed
> >>>This command has been deprecated
> >>When a command is deprecated, it still works the way it did but gives
> >>out a warning about it not being maintained and possible alternatives to it.
> >>If I understand http://review.gluster.org/#/c/7766/ correctly, we are
> >>not supporting these commands any more, in which case the right message
> >>would be "Command not supported"
> >
> >I am wondering if we should even let the command be sent to self-heal-daemons from glusterd.
> >
> >How about
> >06:20:10 :) ⚡ gluster volume heal r2 info healed
> >Command not supported.
> >
> 
> Since we no longer intend supporting this command, it might be
> better to withdraw the command from CLI and have documentation
> reflect the possible alternatives for this command.

I'd like to see an error message that the command has been replaced. The 
message should point to 'gluster volume help $whatever' or the man-page 
in case it has been updated for the new command. Accessing online 
documentation on the internet is not always possible, so try to restrict 
to resources available on the local system.

In addition, a non-zero exit code should be returned. This will help 
authors/users of scripts (in case they exist) to detect unexpected 
behavior.

Thanks,
Niels