Instance destroy renamed to instance remove
ClosedPublic

Authored by lbrabec on Jul 12 2016, 12:22 PM.

Details

Summary

Just a short diff to make @kparal happy.

Test Plan

tested via cli

Diff Detail

Repository
rTCLOUD testcloud
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
lbrabec retitled this revision from to Instance destroy renamed to instance remove.Jul 12 2016, 12:22 PM
lbrabec updated this object.
lbrabec edited the test plan for this revision. (Show Details)
lbrabec added a reviewer: kparal.
lbrabec added a subscriber: kparal.
lbrabec updated this revision to Diff 2370.Jul 12 2016, 12:48 PM
  • docstrings fix
kparal accepted this revision.Jul 12 2016, 12:48 PM

Yay for reasonable names!

This revision is now accepted and ready to land.Jul 12 2016, 12:48 PM
Closed by commit rTCLOUD7c58f028f235: Instance destroy renamed to instance remove (authored by Lukas Brabec <lbrabec@redhat.com>). · Explain WhyJul 12 2016, 12:49 PM
This revision was automatically updated to reflect the committed changes.

I know there aren't many but we do have some folks who use the testcloud cli for testing cloud images

I suspect that I'm going to be the only one tripped up by this change but if I wrote the original and the change makes more sense to you all, it'll probably make more sense to others as well.

That being said, I don't want to get into the habit of changing the cli interface or the library api in non-backwards compatible ways using no ticket and leaving the review posted for 30 minutes before pushing. It's probably harmless in this case but that won't always be the case

Yeah, you're right @tflink, sorry about that. This should have been properly explained and definitely not pushed immediately. Let's remedy the situation a bit:

We will be talking here about stopping and removing a VM. There are two major calls in libvirt to do that:

  • destroy - will immediately destroy a VM, no time to react (similar to SIGKILL)
  • undefine - will remove the VM from libvirt VM listing, i.e. forgetting everything about the VM (you'll no longer see the VM in virt-manager or virsh list --all)

The same two calls in testcloud are these:

  • stop - calls libvirt.destroy
  • destroy - calls libvirt.undefine and removes the VM from testcloud VM listing

My major gripe was the confusion in terminology - testcloud is a wrapper around libvirt, yet it uses "destroy" term for a completely different operation. When I was dealing with issues from D908 and D933, I found it very hard to think and talk about it, when the same word meant a different thing in libvirt and testcloud. We agreed it would make sense to replace it with something that does not overload the original term and conveys the meaning better. We agreed on replacing testcloud's "destroy" with "remove". It better explains what's going to happen and it does not overload the terminology. So now the terminology looks like this:

  • testcloud stop -> libvirt destroy
  • testcloud remove -> libvirt undefine

That feels much better, I think. The "stop" is still somewhat misleading, I think, because it implies the VM is stopped gracefully (sending ACPI shut down signal or similar), which is not the case - the VM is immediately destroyed, same as pulling the power cord. However, we did not want to make too many changes, so we settled for just the once change described above.

Any thoughts regarding this change? Do you agree with it (we can always revert changes)?

If you believe testcloud is being used by a larger audience, we should probably add backwards compatibility, i.e. support destroy on cli and in API for some time, while printing a deprecation message. Any thoughts on that?

Compat options added in D936.