move apko-playground lima template to official lima temples

[developer-guy]

Description

Thanks to @jdolitsky, there is a lima template in the apko repository for people who might want to try apko on their macOS environment, so we (w/@Dentrax) are proposing to add it to the official lima templates.

/cc @kaniini

[jandubois]

I'm not opposed to it, but isn't it easier to maintain in the apko repo, as apko maintainers can make changes as needed instead of opening PRs against Lima?

Note that you can start an instance like this:

limactl start https://raw.githubusercontent.com/chainguard-dev/apko/main/mac/lima/apko-playground.yaml

So I think if the apko maintainers want to move it to the Lima repo, then it is fine with me, but I don't think we should simply mirror it because then it can get out of sync, and we would have to take responsibility of maintaining/syncing it.

[afbjorklund]

Maybe they are just looking for some easier way to keep the base OS updated, and "inherit" that somehow ?

 images:
-- location: "https://github.com/lima-vm/alpine-lima/releases/download/v0.2.23/alpine-lima-std-3.16.0-x86_64.iso"
+- location: https://github.com/lima-vm/alpine-lima/releases/download/v0.2.9/alpine-lima-std-3.14.3-x86_64.iso
   arch: "x86_64"
-  digest: "sha512:2fe71bb7483cb9fa9a6f39b94d46818d27815dbd41bfa060df2846719e0bddf8d9073627a50ed773d7043c996b59182832cd8ce74404cdae09057a5a54b4f1ca"
-- location: "https://github.com/lima-vm/alpine-lima/releases/download/v0.2.23/alpine-lima-std-3.16.0-aarch64.iso"
+  digest: "sha512:fb51cbfe7e6779324adfd835d55a4fa0b702ed66529fe218eb3a9595df8cb31d60d20f8e440674b5dba0f3e43c639a0078828afe36060d245d74ab16f9ce3485"
+- location: https://github.com/lima-vm/alpine-lima/releases/download/v0.2.9/alpine-lima-std-3.14.3-aarch64.iso
   arch: "aarch64"
-  digest: "sha512:f55eb91500b5665eb2000ee71083d3912a2284585bb8f0be5488c805e0527db700b76e823c4d4560407077a4cace566a883a78a7fb7412789d4f8a4a7094f519"
+  digest: "sha512:58ebe295031d7f0010500bde6d9c47b5a3affe6a76ce5a42f400346e954fbb24bdb35ede5e0998e1f9491273821fcc734ba0d50de830c0264e1ba997c245e1e5"

And as we have seen from the k3s/k8s examples, having a good installation script available goes a long way...

  64 examples/k3s.yaml
 165 examples/k8s.yaml

[AkihiroSuda]

Maybe they are just looking for some easier way to keep the base OS updated, and "inherit" that somehow ?

Maybe, we can consider having a new YAML property like inherit: template://alpine

[jandubois]

Maybe, we can consider having a new YAML property like inherit: template://alpine

Yes, it would even be useful for some of the existing templates to inherit from a base OS template.

I guess that means that inheritance would need to be recursive, so you could inherit from e.g. k3s, which in turn inherits from alpine.

One thing we need to be very clear about though: we do not run CI for any downstream templates, so if anything breaks when we update the bundled templates, it is up to downstream to fix that breakage. Of course we will make the base OS images as minimal as possible, to avoid introducing gratuitous breakage from our own modifications.

Oh, and would we support inherit: https://template as well?

[jandubois]

would we support inherit: https://template as well?

I was thinking/hoping the answer would be "yes", but I see additional complications: do we follow the inherit chain every time the VM is restarted or would all the templates be cached?

If we fetch base templates on each restart, how would we handle this if they are no longer available (or the machine is simply offline during the restart)?

[jdolitsky]

wondering if you may just want to allow specifying image overrides with something like

limactl start --tty=false --images=isos/alpine-lima.yaml \
  configs/apko-playground.yaml

or more general like

limactl start --tty=false --overrides=env/canary.yaml \
  configs/apko-playground.yaml

?

[jdolitsky]

isos/alpine-lima.yaml (or env/canary.yaml) would resemble

images:
- location: https://github.com/lima-vm/alpine-lima/releases/download/v0.2.9/alpine-lima-std-3.14.3-x86_64.iso
  arch: "x86_64"
  digest: "sha512:fb51cbfe7e6779324adfd835d55a4fa0b702ed66529fe218eb3a9595df8cb31d60d20f8e440674b5dba0f3e43c639a0078828afe36060d245d74ab16f9ce3485"
- location: https://github.com/lima-vm/alpine-lima/releases/download/v0.2.9/alpine-lima-std-3.14.3-aarch64.iso
  arch: "aarch64"
  digest: "sha512:58ebe295031d7f0010500bde6d9c47b5a3affe6a76ce5a42f400346e954fbb24bdb35ede5e0998e1f9491273821fcc734ba0d50de830c0264e1ba997c245e1e5"

The --images / --overrides flag could point to a remote URL too

[jandubois]

wondering if you may just want to allow specifying image overrides

I don't think it makes sense to artificially restrict the mechanism; but we would effectively get this effect by having base templates that just specify images and not much else.

It would essentially very similar to _config/default.yaml, except the default would be for this specific VM and not for every VM sharing the same $LIMA_HOME.

This could be very useful for e.g. colima, which stores its VM in the default ~/.lima location (iiuc), so any overrides via _config/override.yaml don't affect just the colima instance, but every other one as well.

cc/@abiosoft

[jandubois]

or more general like

limactl start --tty=false --overrides=env/canary.yaml \
  configs/apko-playground.yaml

I didn't see this before, but yes, that is something we should support. Of course this is just syntactic sugar for:

$ cat env/canary.yaml
inherits: configs/apko-playground.yaml
[other settings]

$ limactl start --tty=false env/canary.yaml