Allow editing a running instance

[jandubois]

Right now we display an error when the user tries limactl edit on a running instance.

Instead we should display a prompt and offer the user to stop the instance first (or to abort).

The option to stop the instance should be the default selection, so using limactl edit --yes (see #3345) on a running instance would stop it, perform the edit, and then restart it.

Running limactl edit --yes --set ... should not return until the instance is running again, just as if the user had been running:

limactl stop
limactl edit --set ...
limactl start

---

I can't make up my mind if it would be a good idea to perform the edit operation first before stopping a running instance. That we we can validate the edit first, and skip the restarting if either the new lima.yaml doesn't validate, or if no changes have been made.

But this complicates things quite a bit, just to optimize the failure case, so maybe not worth it.

[unsuman]

I can't make up my mind if it would be a good idea to perform the edit operation first before stopping a running instance. That we we can validate the edit first, and skip the restarting if either the new lima.yaml doesn't validate, or if no changes have been made.

A possible user flow is to first edit and validate the changes, and then we can prompt the user to restart the VM(that requires #3323 ). However, I'm afraid while halting the instance during restart, is it necessary that the YAML file should not be modified(i.e. it should be in the form that the instance was launched in)?

[jonas-peter]

Is this still relevant and something that should be worked on?

[jandubois]

Is this still relevant and something that should be worked on?

Yes.

As to the further discussion about optimization, I think it should work as follows:

1. If this is an interactive edit, the instance should be stopped first before the user can start editing. If the edited lima.yaml does not validate, then the user gets another chance to edit the file until it validates, and only then will the instance restart.

   If the user aborts the editing (using ⌃C to abort a prompt), then the instance will remain stopped.

2. If this is a non-interactive edit (the --set option is specified), then limactl can attempt the edit on a temporary file to verify that the result validates. If it doesn't, then the command fails.

   If the validation succeeds, then the edit will be performed on the actual lima.yaml once the instance is stopped.

[jonas-peter]

@unsuman , are you still working on this?

[jandubois]

@jonas-peter I don't think @unsuman was working on it; we were just discussing the implementation details. He'll be working on the VM plugin/driver project in the future because he won the GSoC slot for it, so I'm sure it is fine if you want to work on this issue.

Let me know if you want me to assign this to you?

[jonas-peter]

Alright. Yes, in this case I will have a look at it, and you can thus assign me.

[jonas-peter]

I like the flow in general.

1. then the instance will remain stopped.

I however do not like that the state of the machine is different on the two cases. If it fails on 1. it is stopped, if it fails on 2. it is still running.

We could make the edit on 1. on a temp file or in memory and only stop the machine and apply it to the file once it is validated. Or we could stop the machine in 2. at the beginning, no matter if input is validated or not.

Or do you have a specific reason why you want it with different states?

[jandubois]

We could make the edit on 1. on a temp file or in memory and only stop the machine and apply it to the file once it is validated. Or we could stop the machine in 2. at the beginning, no matter if input is validated or not.

For the interactive edit we have 2 possible results: the edit validates, or it doesn't:

1. The new lima.yaml validates; the user is presented with a prompt to restart it (status quo):

   ? Do you want to start the instance now?
   

   If the user selects "No" then the instance obviously remains stopped. Otherwise Lima will attempt to start it again. This can still fail, in which case the instance will remain in "Broken" or "Stopped" state. The user is not asked to edit again.

2. The new lima.yaml doesn't validate. We could present the user with 3 choices:

   Do you want to edit the `lima.yaml` again and try to fix the issue?
   Do you want to restart the instance with the original `lima.yaml`?
   Do you want to stop editing and leave the instance stopped with the broken `lima.yaml`?
   

   The last option is identical to what happens if the user aborts with ⌃C.

For the non-interactive edit we don't really have the option of "do you want to continue trying". And there is not really any point to stop the instance, and then restart it with the original lima.yaml if we can predict that this would happen.

So it makes sense to me that the instance will always be running after a non-interactive edit (unless the instance fails to restart due to reasons that validation didn't catch).