[libvirt PATCH 0/5] Formalize the deprecation of arguments in virsh

[Michal Privoznik]

On 3/23/21 3:04 PM, Peter Krempa wrote:
> On Tue, Mar 23, 2021 at 14:50:09 +0100, Michal Privoznik wrote:
>> On 3/23/21 2:42 PM, Daniel P. Berrangé wrote:
>>> On Tue, Mar 23, 2021 at 02:36:19PM +0100, Michal Privoznik wrote:
>>>> On 3/22/21 5:09 PM, Tim Wiederhake wrote:
>>>>> virsh has several arguments that are better not used. This series introduces
>>>>> a formal way of marking them as deprecated.
>>>>
>>>> Commit messages are rather sparse. What we currently have is hiding options
>>>> we deem obsolete from users and replacing them with better ones (just :Ggrep
>>>> VSH_OT_ALIAS). No error message, no warning. What makes these you picked
>>>> special? I'm not against reporting that an option is obsolete, but I don't
>>>> quite understand why we need a different way for obsoleting those three.
>>>
>>> Also the general idea of deprecation is that the thing will be deleted
>>> eventually, which is not something we intended to do with these options.
>>> Basically there's a better way to do these things, but we're not going
>>> to break existing usage, so if users are happy with what they're doing
>>> they don't need to change.
>>>
>>
>> To be fair we never promised virsh to be stable, did we? We are trying to
> 
> I'd say we do, at least for the reasonably machine-usable interfaces
> (for output [1]), thus any input options should be treated as such.
> 
>> keep it as backwards compatible as we can (and so far I guess we didn't have
>> a single instance of bad example), but I wouldn't mind telling users (esp.
>> in interactive mode) that --optionX is now called --optionY.
> 
> Well, that's what we do with the alias and documentation changes. But
> removing --optionX completely would be wrong:

Just to be clear, I am not advocating for removing anything.

> 
> - It needlessly breaks scripts
> - If you decide to print a deprecation warning, the code usually won't
>    be much simpler.
> - most cases are covered by use of _ALIAS to a better name
> 
> The only thing that IMO should be removed but I didn't for compatibility
> is the 'secret-set-value's 'base64' parameter as that is insecure. There
> isn't a compatible replacement though.
> 

That's debatable. Its not much worse than reading from a file. I mean, 
who has access to my $HISTFILE? Only me and root and in both cases the 
secret can be changed or read from the file (if the file is not deleted 
right away, and even then it could be recovered). Many tools accept 
passwords in clear text on cmd line (e.g. curl, wget). If anything, we 
could document why --base64 is dangerous (if we haven't done so yet).

Michal