Get OLM version from cluster

[estroz]

Is there currently a way to retrieve the installed OLM's version from a running cluster through kubectl or client libarary? If not, there should at least be metadata tags on OLM resources, if not a Go client, and perhaps a grpc endpoint, to access version information.

[njhale]

Part of OLM (packageserver) is self-hosted with a CSV that tracks the release version. If you have CSV list privilege in the namespace OLM is installed in, this will give you the version:

$ kubectl -n <olm-namespace> get csvs
NAME                    DISPLAY          VERSION   REPLACES   PHASE
packageserver.v0.10.1   Package Server   0.10.1               Succeeded

Ideally, at some point OLM will be entirely self-hosted, and the CSV name will reflect that (i.e. olm.vx.y.z). Hopefully, among other reasons, this makes pointing to the CSV for OLM info more natural (would love to hear other's thoughts on this).

Alternatively, you can use kubectl exec to directly run the olm or catalog commands for the version:

$ kubectl -n olm exec olm-operator-<pod-suffix> -- olm --version
OLM version: 0.10.1
git commit: b8a4faf

[estroz]

The packageserver CSV version is good enough for our purposes for now. Does the version change between releases, ex. packageserver.{git commit} or is it always fixed to a version?

[njhale]

Does the version change between releases

Each OLM release is a new version. In the previous example, 0.10.1 is the OLM release version.

packageserver.{git commit} or is it always fixed to a version?

We don't include the commit hash, just the semver of the release the manifests are cut for. You can reasonably expect that we won't change OLM manifests once released.

[njhale]

@estroz heads up - in recent versions of OLM we've moved away from versioning the packageserver CSV. This makes the previously discussed kubectl exec path the best bet.

[estroz]

@njhale what about the olm.version label?

[njhale]

what about the olm.version label?

@estroz Nice catch! Yes, you can use that as well.