version: report the cilium images version

[kaworu]

Before this patch:

cilium-cli: v0.5-dev@pr/kaworu/version-report-cilium-version-08338b2 compiled with go1.16.2 on linux/amd64

After:

cilium-cli: v0.5-dev@pr/kaworu/version-report-cilium-version-08338b2 (v1.9.4 images) compiled with go1.16.2 on linux/amd64

[rolinh]

@kaworu I think the idea here was not to report the default cilium version but the version of Cilium that is used in the cluster (if any).

[kaworu]

@rolinh I see, that make sense! While working on #120 I was interested to know which version would be installed by default. Then, I came across the comment in version.go which I mistakenly took for the default Cilium version.

@tgraf Is there any interest in having the default version displayed somewhere in the version output? If not, feel free to close this PR.

[tgraf]

@tgraf Is there any interest in having the default version displayed somewhere in the version output? If not, feel free to close this PR.

Yes, although I was actually planning to fetch the latest version from GitHub directly so we would always automatically install the latest version. I'm planning to do that after the operator version is in.

[kaworu]

I see! So what do you think about a defaults.Version() func? It could just return the constant for now, and allow to implement the "fetch from GitHub" logic in the future.

[rolinh]

I see! So what do you think about a defaults.Version() func? It could just return the constant for now, and allow to implement the "fetch from GitHub" logic in the future.

This makes sense to me as this would allow users to know which Cilium version would be installed by the tool. The Cilium version of a running cluster is already given by cilium status. I think that the fetch from github logic should be easy given that we have a VERSION file in the Cilium repository.

[kaworu]

I think that the fetch from github logic should be easy given that we have a VERSION file in the Cilium repository.

What I had in mind was using the GitHub API to get the latest release because our VERSION file has 1.10.90, e.g.

curl \
  -H "Accept: application/vnd.github.v3+json" \
  https://api.github.com/repos/cilium/cilium/releases | jq -r '.[0].tag_name'

We could do some version compare with the releases to ensure we get the "highest release" rather than the latest (in the curl example we take the latest, but that could well be a v1.9.x release I believe).

[rolinh]

We could do some version compare with the releases to ensure we get the "highest release" rather than the latest (in the curl example we take the latest, but that could well be a v1.9.x release I believe).

In the Hubble repo, we have stable.txt for this purpose actually. It always contains the latest stable released version. Introducing the same concept to the Cilium repository would make sense IMHO.

[kaworu]

Closing to re-open to trigger the PR assignment bot.

[kaworu]

"latest stable Cilium version" detection discussion moved at #272

[tklauser]

Rebased and amended the review comments.

[rolinh]

Awesome, thanks for adding the logic to fetch the latest stable version as well @tklauser 🚀

[tklauser]

After out-of-band discussion with @rolinh we've decided that it probably too risky using the latest stable version as provided in cilium/cilium stable.txt by default. For example, we've had some problems with the update from v1.9.8 to v1.10.1 (see #358 (comment))

Thus, we've decided to keep the built-in default version (defaults.Version) for now and additionaly report the latest stable version in cilium version:

$ cilium version
cilium-cli: v0.8.5-dev@pr/kaworu/version-report-cilium-version-5c7fca26a2b7 compiled with go1.16.5 on darwin/amd64
cilium image (default): v1.10.2
cilium image (stable): v1.10.2

[tklauser]

Connectivity tests on AKS and EKS (tunnel) failed with #367:

https://github.com/cilium/cilium-cli/runs/3017925195?check_suite_focus=true
https://github.com/cilium/cilium-cli/runs/3017924810?check_suite_focus=true