provide another flag to give better understanding about alternative examples in lima

[developer-guy]

Once you first start using lima, you might not understand what you can achieve by using lima in the first place. To make understanding better, we have some mentions of examples/ folder in several places in documents. But what if we provide an alternative command to list all the examples in the first place and let people select one of them to continue with it? @dentrax

$ limactl list-supported-engines # will show us the examples within the examples/ folder
docker
podman
k3s
k8s
...

$ limactl start <instance_name> --engine <docker> # to select one of the engine we provide

WDYT?

[jandubois]

We had a lengthy discussion about something related in #158. Unfortunately we left this dangling, and nothing got implemented.

I think I'm still partial to my suggestion in https://github.com/lima-vm/lima/issues/158#issuecomment-947119612, but we didn't reach agreement on it.

As for terminology, I don't want to reference example configurations as "engines". If anything I would call them "templates".

I've been thinking about supporting something like $LIMA_HOME/_templates as an additional location to store template configurations that could be referenced with a short name.

If you want to work on this area, I think we'll need to spend more time bike-shedding first to reach consensus of how the different pieces should work together.

[afbjorklund]

The use of "engine" here is somewhat confusing, but then so again is the word "runtime". (being used for both "container runtime" as in e.g. CRI and for "OCI runtime" as in runc)

https://developers.redhat.com/blog/2018/02/22/container-terminology-practical-introduction

I think it can be solved by more documentation about the yaml examples, rather than code ?

Anyway, your list is missing the default (nerdctl), but then adding orchestrators next to it... The choice of Linux distribution is also somewhat confusing, since it doesn't change much.

Default	Example	Distro	Engine	Rootless	Orchestrator
-	alpine.yaml	alpine	-	no	-
-	archlinux.yaml	arch	nerdctl	yes	-
-	debian.yaml	debian	nerdctl	yes	-
-	fedora.yaml	fedora	nerdctl	yes	-
-	opensuse.yaml	opensuse	nerdctl	yes	-
-	rocky.yaml	rocky	nerdctl	yes	-
yes	ubuntu.yaml	ubuntu	nerdctl	yes	-
-	docker.yaml	ubuntu	docker	yes	-
-	podman.yaml	ubuntu	podman	yes	-
-	singularity.yaml	fedora	singularity	?	-
-	?	ubuntu	lxc	?	lxd
-	k3s.yaml	ubuntu	containerd	no	kubernetes
-	k8s.yaml	ubuntu	containerd	no	kubernetes
-	nomad.yaml	ubuntu	containerd	no	nomad
-	faasd.yaml	ubuntu	containerd	no	openfaas

One could provide more different combinations, like fedora-podman, if really needed. There is no real practical difference between the nerdctl and "only" containerd, either.

I made some variants with Fedora, but there is no user visible difference. It was just NIH.

We talked about adding more "engines" to Alpine, but for now there is none (but RD) (the nerdctl-full installer doesn't work there, since the distribution doesn't use systemd)

[afbjorklund]

There was some suggestions to add descriptions and icons and links, before...

But it doesn't have to be done in the yaml format, it can be done in markdown.

[jandubois]

It feels like you are over-engineering things now. I think adding a description property to each template, and having a command to list all available templates with their description is fine.

Trying to categorize the templates along multiple dimensions feels like a futile effort: there will always be instances that don't fit into that schema. In the end you can create arbitrary VMs. We ship a list of examples with Lima, both to show users different ways the lima configuration system can be used, and to give people a useful starting point to customize their own.

But if this is turning into a full-blown app-store for virtual appliances, then I think that should probably be a website that is maintained independently of the Lima tool itself. It could still be part of the lima-vm org though, but should be a separate repo and requires some commitment of long-term maintenance. I'm afraid it would suffer the typical fate of a wiki: initially maintained with enthusiasm, but eventually getting out-of-date, full of unmaintained cruft.

So my opinion is to start small, with incremental improvements.

[afbjorklund]

I think that is the same conclusion that we came to the last time, and it hasn't really changed since. :-)

Having two distributions (alpine and ubuntu) and two orchestrator distributions (k3s and k8s) feels like plenty ?

If I understood correctly, the main point was starting a machine with nerdctl (and containerd and buildkitd)

It's nice that you can use lima to run "other" systems as well, such as docker and podman, but not really key.

[afbjorklund]

To be honest, I don't think that Ubuntu is very important here either. It just happens to be well known...

It has its own agenda, with the snapd and the lxd and the other cruft, as well as multipass and microk8s.

But if ever needed, one could do an "ubuntu-lima" and customize it a bit (similar to "alpine-lima" today) ?

Currently I don't think the added maintenance is worth possibly reducing the footprint or slightly better fit.

[jandubois]

FWIW, there are no pre-built public Alpine images with cloud-init, afaik. So there was no choice but to build a custom image.

Generally I think it is not worth it to create custom images for all the distros. We don't want to replicate the AWS maketplace for AMIs. 😄

What we may want to do eventually is to add support for copying/cloning existing instances. So you could setup and customize your master instance, and then stop it. Any time you need a pristine image, you copy/clone from this master image instead of starting from scratch. Maybe use hardlinks for the original image file (baseDisk), to save some disk space.

This allows much more flexibility in users creating their own template images, without putting the maintenance burden on somebody else.

[afbjorklund]

Generally I think it is not worth it to create custom images for all the distros. We don't want to replicate the AWS maketplace for AMIs. :smile:

I only meant the "default" images.

[AkihiroSuda]

I'd like the UI (tty mode) to be like this

$ limactl start
? Creating an instance "default" from template://default [Use arrows to move, type to filter]
  Proceed with the current configuration
> Choose another template (alpine, archlinux, debian, docker, ...)  
  Open an editor to override the configuration
  Exit

? Choose an instance [Use arrows to move, type to filter]
   alpine       - Alpine Linux
   archlinux    - Arch Linux
   debian       - Debian GNU/Linux
   default      - Default (Ubuntu)
   docker       - Docker, on Ubuntu
   faasd        - faasd on Ubuntu
   fedora       - Fedora
   k3s          - k3s on Ubuntu
>  k8s          - Kubernetes on Ubuntu
   nomad        - Nomad on Ubuntu
   opensuse     - openSUSE Leap
   podman       - Podman on Ubuntu
   rocky        - Rocky Linux
   singularity  - Singularity (Apptainer) on Fedora
   ubuntu       - Ubuntu (same as "default" but simplified)
   vmnet        - vmnet.framework with Ubuntu

? Creating an instance "default" from template://k8s [Use arrows to move, type to filter]
> Proceed with the current configuration
  Choose another template (alpine, archlinux, debian, docker, ...)  
  Open an editor to override the configuration
  Exit
...

For non-tty mode, CLIs should be like this

$ limactl start --tty=false --name=default template://k8s

[afbjorklund]

I would avoid the "on Ubuntu" parts.

[afbjorklund]

I called it the "quick" version of create, as in quick start that is.

Here is a graphic version, that I was playing with for the GUI:

The "Advanced..." button would open up the regular YAML editor.

The overrides (or parameters) should probably have popups/sliders.

[afbjorklund]

Added a checkbox for dropping into the yaml editor after preloading the template, for changing things:

Not sure where the other parameters should actually go, if they should be merged into the YAML file ?

Also how to get those default values, I could hardcode 4 CPUs and 4GiB Memory and 100GiB Disk.

---

Added an url to each example, so that one can click that link and read more on web if interested:

• https://github.com/afbjorklund/lima/blob/master/examples/README.md

• https://github.com/afbjorklund/lima-gui/blob/main/examples.cpp

[AkihiroSuda]

Implemented in https://github.com/lima-vm/lima/pull/674