[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] Request to rename 'destroy' to something milder.

On 06/14/2011 04:26 PM, Kashyap Chamarthy wrote:
> 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..

Oh, sorry for typos in my last e-mail. I noticed them now however you
obviously understood what I meant ;-) In fact if we mark something
obsolete then user should get used to new commands instead of the old
ones however preserving backwards compatibility is necessary.

One day, when the latest version switch from 0.9.2 (now from what I
know) to e.g. 1.5.0 user shouldn't be using the obsolete functions at
all so we should be able to get rid of them.

That's just my understanding of this and maybe it's wrong but I guess it
won't make issues by the date of e.g. 1.5.0 release.


Michal Novotny <minovotn redhat com>, RHCE
Virtualization Team (xen userspace), Red Hat

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]