(please cc me in response as I have not subscribed to this list) Hi all, A minor nitpick: Every-time I suggest someone to do a force shut-down a guest using 'virsh destroy foo' , the very first question I get is -- does it _destroy_ my data? This causes confusion to the inexperienced user and makes him/her suspect that the data/disk could be destroyed while running 'virsh destroy foo' Maybe replacing it to a milder name like 'poweroff' or something might help? Thanks, Kashyap Chamarthy -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

On 14.06.2011 12:31, Kashyap Chamarthy wrote: > (please cc me in response as I have not subscribed to this list) > > Hi all, > > A minor nitpick: > > Every-time I suggest someone to do a force shut-down a guest using > 'virsh destroy foo' , the very first question I get is -- does it > _destroy_ my data? > > This causes confusion to the inexperienced user and makes him/her > suspect that the data/disk could be destroyed while running 'virsh > destroy foo' > > Maybe replacing it to a milder name like 'poweroff' or something might > help? Libvirt has this philosophy to be backward compatible and therefore not to change old API including virsh commands. But as time flies, some APIs are consumed by new ones (virDomainCreateLinux is now just alias for virDomainCreateXML). So changing this is not feasible way. What might be, is to create less invasive aliases. But we can't make 'destroy' command to go away.

On 06/14/2011 07:53 PM, Michal Novotny wrote: > On 06/14/2011 04:15 PM, Michal Privoznik wrote: >> On 14.06.2011 12:31, Kashyap Chamarthy wrote: >>> (please cc me in response as I have not subscribed to this list) >>> >>> Hi all, >>> >>> A minor nitpick: >>> >>> Every-time I suggest someone to do a force shut-down a guest using >>> 'virsh destroy foo' , the very first question I get is -- does it >>> _destroy_ my data? >>> >>> This causes confusion to the inexperienced user and makes him/her >>> suspect that the data/disk could be destroyed while running 'virsh >>> destroy foo' >>> >>> Maybe replacing it to a milder name like 'poweroff' or something might >>> help? >> Libvirt has this philosophy to be backward compatible and therefore not >> to change old API including virsh commands. But as time flies, some APIs >> are consumed by new ones (virDomainCreateLinux is now just alias for >> virDomainCreateXML). So changing this is not feasible way. What might >> be, is to create less invasive aliases. But we can't make 'destroy' >> command to go away. > Hi Michal, > that's right and that's right I've recommended adding the new command > 'poweroff' to be an alias for the 'destroy'. We can do rename right now > but we can mark 'destroy' as obsoleted with backwards compatibility and > issue the 'poweroff' command instead. If the 'destroy' command is marked > as obsoleted at least in the virsh case we can remove the 'destroy' > command one day theoretically since it will be no longer supported way > to poweroff the guest. And by 'one day' I mean in several minor (or even > major) of libvirt. Michal, yep, this sounds perfectly reasonable. And doesn't break any backward compatibility..

On 06/14/2011 04:31 AM, Kashyap Chamarthy wrote: > (please cc me in response as I have not subscribed to this list) > > Hi all, > > A minor nitpick: > > Every-time I suggest someone to do a force shut-down a guest using > 'virsh destroy foo' , the very first question I get is -- does it > _destroy_ my data? > > This causes confusion to the inexperienced user and makes him/her > suspect that the data/disk could be destroyed while running 'virsh > destroy foo' > > Maybe replacing it to a milder name like 'poweroff' or something might > help? I don't know how successful you'll be at this.

point in the past about adding 'nodedev-detach' as an alias for 'nodedev-dettach' to fix the spelling error (but I can't find it in the mail archives, so it was probably a question I asked on IRC). My recollection of the response is: 1. any client that cares about maximum portability will use the older spelling, not the newer one, so adding won't help portable scripts.

2. adding an alias means that the user writing a new script has to read the documentation to see which of the two commands they want to use, whereas offering only one spelling makes the decision easier. 3. while we may mark old spellings as deprecated, we have no plans to remove them at any point (not even for a major number bump); backwards compatibility demands that we keep everything we ever add, and adding aliases adds that much more to maintain (although the maintenance burden of an alias is lighter than the burden for a new API). I'm personally in favor of the idea of adding better-named aliases, so I'm not the person to convince. For this idea to work, you'll need buy-in from the Daniels (DV and danpb). And we _do_ have at least one example of an alias: 'virsh quit' and 'virsh exit' are aliases.