Reduce usage of `//go:embed` (`containerd.yaml`, `networks.TEMPLATE.yaml`, etc.)

[AkihiroSuda]

As in regular template YAMLs (/usr/local/share/lima/templates/*.yaml), containerd.yaml, networks.TEMPLATE.yaml, etc. could be read from the local directory rather than from //go:embed?

https://github.com/search?q=repo%3Alima-vm%2Flima+%22%2F%2Fgo%3Aembed%22&type=code

lima/pkg/limayaml/defaults.go

Lines 61 to 62 in 434aabe

	//go:embed containerd.yaml
	var defaultContainerdYAML []byte

lima/pkg/networks/config.go

Lines 23 to 24 in 434aabe

	//go:embed networks.TEMPLATE.yaml
	var defaultConfigTemplate string

lima/pkg/cidata/template.go

Lines 25 to 31 in 434aabe

	//go:embed cidata.TEMPLATE.d
	var templateFS embed.FS
	const templateFSRoot = "cidata.TEMPLATE.d"
	//go:embed wincidata.TEMPLATE.d
	var windowsTemplateFS embed.FS

lima/pkg/autostart/launchd/launchd.go

Lines 19 to 23 in 434aabe

	//go:embed io.lima-vm.autostart.INSTANCE.plist
	var Template string
	//go:embed io.lima-vm.daemon.INSTANCE.plist
	var DaemonTemplate string

lima/pkg/autostart/systemd/systemd.go

Lines 19 to 20 in 434aabe

	//go:embed lima-vm@INSTANCE.service
	var Template string

Driver-specific embeds (may stay embedded?)

lima/pkg/driver/wsl2/vm_windows.go

Lines 72 to 73 in 434aabe

	//go:embed lima-init.TEMPLATE
	var limaBoot string

lima/pkg/driver/wsl2/wsl_driver_windows.go

Lines 176 to 177 in 434aabe

	//go:embed boot.Linux/*.sh
	var bootLinuxFS embed.FS

lima/pkg/driver/vz/vz_driver_darwin.go

Lines 231 to 232 in 434aabe

	//go:embed boot.Linux/*.sh
	var bootLinuxFS embed.FS

lima/pkg/driver/krunkit/krunkit_driver_darwin_arm64.go

Lines 288 to 289 in 434aabe

	//go:embed boot.Linux/*.sh
	var bootLinuxFS embed.FS

Guest agent embeds (should stay embedded probably, as the guest agent binary has been expected to be a single file)

lima/cmd/lima-guestagent/install_systemd_linux.go

Lines 112 to 113 in 434aabe

	//go:embed lima-guestagent.TEMPLATE.service
	var systemdUnitTemplate string

[afbjorklund]

Guest agent embeds (should stay embedded probably, as the guest agent binary has been expected to be a single file)

The OpenRC template for lima-guestagent is "missing". That is, it is in the template and not in the single file?

lima/pkg/cidata/cidata.TEMPLATE.d/boot.Linux/25-guestagent-base.sh

Line 66 in 434aabe

print_config >/etc/conf.d/lima-guestagent

[jandubois]

Is this really a good idea?

Previously we used to claim that e.g. lima.env is not a supported API, and now we are making all the boot scripts editable? How are we going to tell in bug reports if this is Lima using the pristine data files, or if there are modifications?

What are the advantages of having these editable instead of requiring the user to build their own binary if they want to change them?

If you really think we need this, then I think the default should still be using embedded files, with an option (e.g. environment variable) to override. But I think even that is not a good idea.

[AkihiroSuda]

editable

They don't need to be editable, but should be readable for "transparency"

[jandubois]

readable for "transparency"

They are readable the same way as the Go source. It doesn't make sense to me to store them externally unless the user is supposed to edit them, which then makes them a public API, meaning we can no longer easily change how those files are used, or what they do.

[afbjorklund]

The user is not supposed to edit the containerd defaults, only (maybe) override them.

Even though they were converted from go to yaml, they are still "in the code".

#  # Override containerd archive
#  # 🟢 Builtin default: hard-coded URL with hard-coded digest (see the output of `limactl info | jq .defaultTemplate.containerd.archives`)
#  archives:
#  - location: "~/Downloads/nerdctl-full-X.Y.Z-linux-amd64.tar.gz"
#    arch: "x86_64"
#    digest: "sha256:..."

The only "tricky" part is converting from json to yaml, but you could use | yq -P.

limactl info | jq .defaultTemplate.containerd.archives | yq -P

- location: https://github.com/containerd/nerdctl/releases/download/v2.3.5/nerdctl-full-2.3.5-linux-amd64.tar.gz
  arch: x86_64
  digest: sha256:b697295c623639734aaab737523c808fd3cc8d3046039fd94fff1744e4c317aa
- location: https://github.com/containerd/nerdctl/releases/download/v2.3.5/nerdctl-full-2.3.5-linux-arm64.tar.gz
  arch: aarch64
  digest: sha256:6e4b687f1d138e750a3c8372abc0f81d3d7490b6359c48c0562fc7dfe98859b2

[AkihiroSuda]

limactl info | jq .defaultTemplate.containerd.archives | yq -P

I expect there to be a "static" way to check the archive information without running a binary.
It is still included in the source code, but hard to find.

[afbjorklund]

It would be possible to move the containerd images from the code, to the templates...
Like how we do it for the ubuntu images, for instance (i.e. being loaded from _images)

Maybe that would also open up for caching other images, like the podman distribution
(nerdctl-full installs everything you need for nerdctl, while podman-full installs podman)

---

It would make containerd.archives mandatory to set, I suppose?

i.e. if you enable either of "user" or "system", you need "archives" too

images: []
mounts: []
containerd: null

base:
- template:_images/ubuntu
- template:_default/mounts
- template:_default/containerd

templates/_default/containerd.yaml

containerd:
  system: false
  user: {{if or eq .HostArch "x86_64" eq .HostArch "aarch64"}}true{{else}}false{{end}}
  archives:
  - location: https://github.com/containerd/nerdctl/releases/download/v2.3.5/nerdctl-full-2.3.5-linux-amd64.tar.gz
    arch: x86_64
    digest: sha256:b697295c623639734aaab737523c808fd3cc8d3046039fd94fff1744e4c317aa
  - location: https://github.com/containerd/nerdctl/releases/download/v2.3.5/nerdctl-full-2.3.5-linux-arm64.tar.gz
    arch: aarch64
    digest: sha256:6e4b687f1d138e750a3c8372abc0f81d3d7490b6359c48c0562fc7dfe98859b2

[AkihiroSuda]

template:_default/containerd sounds good, but it is a breaking change.

Do we need to have _implicit/ templates to specify the implicit default values that do not need explicit base: ?
Can be even more complicated though.