Add Version Command

[nick-potts]

It's not straightforward to check what version of the daemon is running on a machine. This adds a uc version command that displays both the client and server versions.

[nick-potts]

Might make more sense if this outputs the version on every machine in the cluster actually

[jabr]

Might make more sense if this outputs the version on every machine in the cluster actually

There is a function ProxyMachinesContext that creates a new context.Context that will call your new GetVersion on every machine (or an optional subset).

You just pass that as the context to clusterClient.GetVersion(*listCtx*) instead of the original ctx, and then it returns an array of results with responses for each machine. You can find a few examples of usage in the current source, like this one for uc volume ls: https://github.com/psviderski/uncloud/blob/main/pkg/client/volume.go#L58

However, if I remember correctly, the returned metadata on each response just has the machine's IP address, not the name. So most of the code using it also has some code that maps the IP on each to the user's name for the machine to make the command output more friendly.

(Aside, that recurring pattern of mapping the machine metadata to the user-friendly machine name is probably something we should refactor to de-duplicate across commands. Definitely a task for a separate MR, imo, though.)

Here's another example of usage in uc ps where I built the IP->name map in one go at the beginning:

• https://github.com/psviderski/uncloud/blob/main/cmd/uncloud/ps.go#L185-L196

And then the code for the lookup as I loop through each machine's result payload:

• https://github.com/psviderski/uncloud/blob/main/cmd/uncloud/ps.go#L213-L226

Note also the special handling of if msc.Metadata != nil { ... } as it does not set that Metadata if there is only one machine in the list context. Another bit we should clean up or hide behind a developer friendlier implementation of this logic, I think.

update: a quick first pass at the refactored ProxyMachinesContext idea here: #247

[nick-potts]

Outputs this now. Decided to put it on the MachineInfo instead.

./uc version
Client: 0.1.0-dev

MACHINE        STATE   VERSION
machine-amfv   Up      0.1.0-dev
machine-ipni   Up      (unknown)

[jabr]

Decided to put it on the MachineInfo instead.

Ah, yeah, that's a good idea. Makes sense for the machine info to include (and near zero overhead), as I imagine it could be useful for other purposes. For example, I think there was a discussion in discord about how the cli should output a smarter error if the issue is the daemon needing an upgrade, etc.

[psviderski]

Superseded by 8b95db6, 8aa0a96, and ad43569 that make each machine the source of truth for its MachineInfo that is periodically synced to the corrosion store.
Also publish OS name, kernel version, arch, docker version, and daemon version:

NAME           STATE   ADDRESS         PUBLIC IP        WIREGUARD ENDPOINTS                       OS                   KERNEL              ARCH    DOCKER   VERSION
machine-cirv   Up      10.210.0.1/24   xx.xx.xx.xx      192.168.40.243:51820, xx.xx.xx.xx:51820   Debian 12.12         6.1.0-41-amd64      amd64   29.4.0   999.0.0-dev
vps2           Up      10.210.1.1/24   xxx.xx.xxx.xxx   10.0.0.95:51820, xxx.xx.xxx.xxx:51820     Ubuntu 22.04.5 LTS   6.8.0-1050-oracle   arm64   29.5.3   999.0.0-dev