feature request: add lxd version to amc node list

[Samuel Allan]

Requesting:
- lxd node version to `amc show <node>`
- lxd node version to `amc node list` with a new flag to include a wider table like `-o wide`
- lxd node version to `amc node list --format json`

This will be useful to get an overview of the versions without querying each lxd unit.

[Simon Fels (morphis)]

The LXD cluster must be at the same version for all nodes and LXD will force nodes to upgrade under the hood automatically. How does this help? What information can you get from this being included in the `amc node list` output?

[Samuel Allan (samuelallan)]

That's true, but it would be helpful to check the running version of lxd on each node during/after upgrades. We feel it may help catch issues, since upgrading a multi-node lxd cluster must be done one at a time. Unless of course I'm misinterpreting the upgrade process (involving juju run lxd/N upgrade).

[Nobuto Murata (nobuto)]

In a bigger picture, we'd like to see the consolidated output about components we are running in an Anbox Cloud cluster.

For example, there are multiple steps in the upgrade process and some of the actions will be run on node by node basis. It would be nice if we can have a single view, what upgrade has been done and what's remaining in one single status list.

I'm not suggesting we should replicate the following. But this kind of status list including the version of each component, roles, necessary attributes like CPU architecture would be helpful for operators to understand the picture of the deployment.

$ kubectl get node
NAME STATUS ROLES AGE VERSION
microk8s Ready <none> 2m2s v1.26.4

$ kubectl get node --show-labels
NAME STATUS ROLES AGE VERSION LABELS
microk8s Ready <none> 80s v1.26.4 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=microk8s,kubernetes.io/os=linux,microk8s.io/cluster=true,node.kubernetes.io/microk8s-controlplane=microk8s-controlplane

[Launchpad Janitor (janitor)]

[Expired for Anbox Cloud because there has been no activity for 60 days.]

[Samuel Allan (samuelallan)]

Is this something that the anbox team might be interested in looking at? Maybe we can discuss sometime about what this could look like? :)

[Simon Fels (morphis)]

> That's true, but it would be helpful to check the running version of lxd on each node during/after upgrades. We feel it may help catch issues, since upgrading a multi-node lxd cluster must be done one at a time. Unless of course I'm misinterpreting the upgrade process (involving juju run lxd/N upgrade).

As you're running the upgrade process via Juju, doesn't `juju status` already show you the LXD version you're running? Replicating that info within AMS might also be not always possible as we need to rely on what LXD tells us and if it doesn't respond during a failed upgrade (LXDs REST API wont respond if it can't get the cluster online) the `amc node ls` output would not really help you.

[Simon Fels (morphis)]

> I'm not suggesting we should replicate the following. But this kind of status list including the version of each component, roles, necessary attributes like CPU architecture would be helpful for operators to understand the picture of the deployment.

That's a different story but isn't that Juju's stop as it can determine that a lot better than AMS can ever do. The Juju output should provide you the exact version of all the components we're running already and will update automatically as things are upgraded.