limactl start vs create - where to draw the line?

[jay7x]

As you may see in the latest commits limactl create was introduced recently in HEAD (not released yet atm). This commands mostly just creates the VM definition currently. Then limactl start do the rest (download files, do some sanity checks, run the VM).

Question is.. where to draw the line between those commands.

Discussion is transferred from slack:

Yury Bushmelev
though, as I see, all the downloads happen in the start action anyway

Jan Dubois
That is an interesting point. I noticed some of our parameter validation also only happens when you start (e.g. checking that you cannot use virtiofs with qemu on macOS). I wonder if all the downloading and checking should happen at create time

Jan Dubois
You can run create, edit, validate and still have the instance fail to start up because of configuration errors. That feels wrong.

Yury Bushmelev
and maybe I’d like to have ability to --download-only 🙂

Jan Dubois
idk, I would like to see this discussed in a Github issue: should create download images right away? Should edit be able to change the image (sounds dangerous)? I don't have a settled opinion on these things, but they feel like they would fit into a more composable "API" like we get by separating create from start. Creating the disk image logically belongs to create in my mind.

Yury Bushmelev
I have no strong opinion here.. I see the point to have all the things under start but it’s ok to expect to have them under create too.. let’s have an issue or discussion for this

Jan Dubois
E.g. once you have created the instance, you should be able to start it even when you are offline.

Please share your thoughts! Thank you!

[AkihiroSuda]

👍 on let limactl create download the images and do some sanity checks. i.e., everything except running the VM

(PR is welcome)

[jandubois]

It'd be nice to have limactl create ... --start which call the start action in the end.. (and limactl stop --rm too).

But why? This is completely redundant with limactl start.

Same thing for limactl stop --rm. This is the same as limactl delete -f, except slower because it would wait for a graceful shutdown before deleting the instance anyways. Why do we need an extra option for this?

Personally I don't like having many different subcommands and options that do the same thing¹. It is confusing for a person just learning about Lima and provides no actual value. I make exceptions for maintaining backwards compatibility, but am strongly against adding complexity for no reason beyond "because we can".

Subcommands/options should be orthogonal, composable, and easy to figure out.

Footnotes

1. I realize that this is somewhat ironic, coming from a retired Perl maintainer. ↩

[afbjorklund]

The only issue that I have is that I remove some instances to save spaces, and then forget that I have done so...

And then when it is not running, I try to start it and run into something similar to limactl start docker.

INFO[0000] Creating an instance "docker" from template://default (Not from template://docker) 

But at this point (backwards compatible), it might be hard to ever remove the create from the start anyway?

[afbjorklund]

The "others" do this, in case it was unclear why I was expecting it:

$ docker-machine start
Error: No machine name(s) specified and no "default" machine exists

$ podman machine start
Error: podman-machine-default: VM does not exist

However, "minikube start" works the same way as "limactl start" does.

[AkihiroSuda]

PR:

• limactl create: prepare images #1677