canonical
delete is all-or-nothing
If I call multipass delete -p vm1 vm2 vm3, it only succeeds if all three machines exist. If one of the machines doesn't exist, the entire command aborts without doing anything.
#!/bin/bash
multipass delete -p vm1 vm2 vm3
multipass launch daily:bionic --name vm1
multipass launch daily:bionic --name vm2
multipass launch daily:bionic --name vm3
This fails if vm2 was already deleted, but the others still exist:
delete failed: The following errors occurred:
instance "vm2" does not exist
launch failed: instance "vm1" already exists
This becomes tedious in scripts, because you now have to delete each machine individually to make sure it succeeds:
multipass delete -p vm1
multipass delete -p vm2
multipass delete -p vm3
...
Somewhat related: Why does delete without -p shut down the VM? Couldn't it just be multipass shutdown vm1 and multipass delete vm1?
@kstenerud to answer your second question, multipass delete is only marking the instance for deletion (think recycle bin) so you don't lose data by accident. Where possible we suspend it, so if you then multipass recover, you don't lose anything. multipass purge then actually kills the VMs marked for deletion.
When passing -p, it's the nuclear option of purging the instance straight away.
As to the original issue, if scripting, why wouldn't your script know whether vm2 exists or not?
If you'd just run multipass delete -p vm2, would you consider it a success if it didn't exist in the first place? I tend to think of CLI commands as asking for a result rather than asking for a process to ensue, so I could get convinced of that.
But without -p, the ask is for the instance to be marked for deletion, so if it doesn't exist, I'd call that an error.
FWIW we have a similar discussion in #545 about multipass restart.
Mostly I'm thinking about idempotency. Most public APIs do this so that they consider only the end result when reporting success or failure. If the object to be purged doesn't exist, the end result (the object doesn't exist) is true, therefore the API call returns true.
However, since "delete" serves a different purpose (move to a deletion pool rather than actually delete), this wouldn't make sense for the delete call...
I agree with the ask for idempotency, so my proposal:
- on
delete, if the instance doesn't exist, it's an error - on
delete <multiple>, existing instances get deleted, it's still an error if any of them don't exist - on
delete --purge, missing instances is not an error, since the result is achieved already
@ricab @gerboland @townsend2010 what do you guys think?
What about:
multipass deletemarks for deletion, like before. Deleting non-existent machines is an error.multipass purgepurges if all selected existing machines are marked for deletion, fails otherwise. Purging non-existent machines is OK.multipass purge --forcemarks machines for deletion if they're not already, and purges them. Purging non-existent machines is OK.
Actually, on second look that's pretty similar, just from the purge side. I'd be more partial to --force since it matches many unix commands (as in just do it, getting to the desired end result by whatever means necessary).
@kstenerud,
I'm not a fan of changing the semantics of purge like that. purge has never taken instance names as arguments and changing that will probably confuse many current users. We'd have to be very proactive on communicating a big UI change like that. And I don't see any huge gains in this either since what you propose can essentially be accomplished with how delete and purge behave today along with @Saviq's proposed changes to delete.
@Saviq, @gerboland, @ricab, any opinions?
@kstenerud as Chris wrote above, purge does not take instance names as arguments, it acts on all deleted ones. The --force behaviour you describe is achievable by delete --purge, I'd stick with that.
@Saviq yep, I agree that makes most sense. It also matches what rm or trash do.
