Add optional message to be shown to template

[afbjorklund]

Show example with current values already in place.

Currently just shown as regular INFO log messages.

As mentioned in #470 (comment)

Example:

INFO[0032] [hostagent] The final requirement 1 of 1 is satisfied 
INFO[0032] READY. Run `limactl shell docker` to open the shell. 
INFO[0032] To run `docker` on the host (assumes docker-cli is installed): 
INFO[0032] $ export DOCKER_HOST=unix:///home/anders/.lima/docker/sock/docker.sock 
INFO[0032] $ docker ...                                 

[jandubois]

I like it!

1. Needs (commented out) sample setting/documentation in pkg/limayaml/default.yaml.

2. Should use the addGlobalFields logic from cmd/limactl/list.go (move it to the store package, so it can be shared). That way we have the same set of template variables (adds IdentityFile and LimaHome for now).

[jandubois]

Thanks, LGTM

[AkihiroSuda]

I think we have to consolidate this struct into what we have for sockets

lima/pkg/limayaml/defaults.go

Lines 197 to 206 in 7d3eca5

	data := map[string]string{
	"Dir": instDir,
	"Home": home,
	"Name": filepath.Base(instDir),
	"UID": user.Uid,
	"User": user.Username,
	"Instance": filepath.Base(instDir), // DEPRECATED, use `{{.Name}}`
	"LimaHome": limaHome, // DEPRECATED, (use `Dir` instead of `{{.LimaHome}}/{{.Instance}}`
	}

Having two similar but different structs is confusing.

[afbjorklund]

We consolidated the one from "limactl list", but didn't do anything about the socket templates

[AkihiroSuda]

Thanks, but I think we have to consolidate the template struct into what we already have for sockets

https://github.com/lima-vm/lima/pull/472/files#r767601007

[jandubois]

Thanks, but I think we have to consolidate the template struct into what we already have for sockets

I don't think that works too well.

For guestSocket the Home and User fields have different values; the user inside the VM may be lima if the host user is not valid, and Home is /home/$USER.linux.

For hostSocket we support additional "deprecated" fields, that we don't want to show up in limactl list --list-fields.

If we want to consolidate, then we can only do this for hostSocket, but we would also have to add tags on the deprecated fields, and check for them in the reflection code that lists field names.

[jandubois]

For hostSocket we support additional "deprecated" fields, that we don't want to show up in limactl list --list-fields.

Turns out InstanceDir (redundant with plain Dir) is the only field we want to hide, as LimaHome is used by limactl list.

[afbjorklund]

I found another issue with architecture, it was amd64 on the host but translated to x86_64 in the VM.

Arch

HostArch

I didn't end up using it now, but thought it might come in handy for instance when downloading a client...

[jandubois]

I found another issue with architecture, it was amd64 on the host but translated to x86_64 in the VM.

Can you point to where it is used as amd64 (except in HostArch in this PR)?

I would say that HostArch should be set to x86_64 to be consistent with the values we use in lima.yaml (aarch64 and x86_64.

I don't think we need to include the GOARCH values as well; you can use templating to translate, if you really have to:

curl ... tarball.{{if eq .HostArch "x86_64"}}amd64{{else})arm64{{end}}.tar.tz

We can always add more names later, if they seem to be useful, but we can't remove them without breaking compatibility, so I would not add more than we need. I'm fine with HostArch and HostOS though.

[afbjorklund]

Can you point to where it is used as amd64 (except in HostArch in this PR)?

It wasn't used per se, I just happened to list both in the same template test...

But maybe should use the lima function to set them, instead of the "raw" vars

like resolveArch does it

type Arch

[AkihiroSuda]

Thanks