Implement support for global default.yaml and override.yaml configs

[jandubois]

Stored inside the _config directory, they provide defaults for all instances stored under the same LIMA_HOME. Settings from override.yaml take precedence over the instance settings themselves:

$ cat ~/.lima/_config/override.yaml
mounts:
- location: "~"
  writable: true
- location: /Volumes/ThunderBlade
  writable: true

networks:
- lima: shared

This make the home mount writable, adds a second mount point (because I have symlinks that point to an SSD array), and adds a vmnet IP address to every instance I start, without me having to modify the examples/*.yaml file when I create the instance.

The settings could have been in _config/default.yaml too, except making ~ writable wouldn't work because we make it explicitly readonly in our sample configs.

This mechanism also allows users of Rancher Desktop or Colima to modify the config of the embedded instance without worrying about getting their customizations wiped during app updates, or instance restarts.

Still needs polishing and more testing (and updating the docs), but otherwise fully functional, so please give some feedback!

[AkihiroSuda]

~/.lima/_config/override.yaml

Maybe we want to support multiple override yamls?
~/.lima/_config/override/{00-foo.yaml, 01-bar.yaml, ...}

[jandubois]

Maybe we want to support multiple override yamls?

Can you explain the use case?

[AkihiroSuda]

Maybe we want to support multiple override yamls?

Can you explain the use case?

I was thinking that splitting the override yaml into multiple files may increase readability of the yamls, but we can revisit that later.

[AkihiroSuda]

Looks good after adding docs and tests.
Especially we should clarify how the default yaml and the override yaml are applied to []string fields such as .mounts and .containerd.archives.

[jandubois]

I was thinking that splitting the override yaml into multiple files may increase readability of the yamls, but we can revisit that later.

I think the overrides or defaults will typically be very small, so splitting them into multiple files doesn't make that much sense.

The one exception would be provisioning and probe scripts. But I think a better solution for those would be to allow them to be filename references and not require them to be inlined into the YAML file. That would allow you to use a proper "shell" mode for editing them, and also enables running shellcheck against them etc.

So yeah, we can revisit later, but I don't expect that there will be a need for this.

However, what we will need eventually is a per-instance override that will be stored inside the instance directory, and can be used to store modified setting specified e.g. via limactl start alpine --set cpus=2. But this can wait until we actually have a way to modify settings during restarts.

[jandubois]

@AkihiroSuda PTAL, I think it is basically done now

[jandubois]

Sorry, pushed one more update to allow "merging" of networks using Interface as the shared key. That will allow the override.yaml to change the network type of a named interface e.g. form "shared" to "bridged".

The docs at the bottom of default.yaml feel rather verbose, but not sure how to tighten them up.

[AkihiroSuda]

Thanks