Description of problem: Currently, we could not find the exact version info for the olm/catalog. Version-Release number of selected component (if applicable): 3.11 brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/ose-operator-lifecycle-manager:v3.11 How reproducible: always Steps to Reproduce: 1. Install the OLM. 2. Access their pods. 3. Check the olm/catalog help info. Actual results: Could not find any option to display their version info. sh-4.2$ olm --help Usage of olm: -alsologtostderr log to standard error as well as files -debug use debug log level -interval duration wake up interval (default 5m0s) -kubeconfig string absolute path to the kubeconfig file -log_backtrace_at value when logging hits line file:N, emit a stack trace -log_dir string If non-empty, write log files in this directory -logtostderr log to standard error instead of files -stderrthreshold value logs at or above this threshold go to stderr -v value log level for V logs -vmodule value comma-separated list of pattern=N settings for file-filtered logging -watchedNamespaces -watchedNamespaces="" comma separated list of namespaces for alm operator to watch. If not set, or set to the empty string (e.g. -watchedNamespaces=""), alm operator will watch all namespaces in the cluster. sh-4.2$ catalog --help Usage of catalog: -alsologtostderr log to standard error as well as files -debug use debug log level -interval duration wakeup interval (default 15m0s) -kubeconfig string absolute path to the kubeconfig file -log_backtrace_at value when logging hits line file:N, emit a stack trace -log_dir string If non-empty, write log files in this directory -logtostderr log to standard error instead of files -namespace string namespace where catalog will run and install catalog resources (default "tectonic-system") -stderrthreshold value logs at or above this threshold go to stderr -v value log level for V logs -vmodule value comma-separated list of pattern=N settings for file-filtered logging -watchedNamespaces string comma separated list of namespaces that catalog watches, leave empty to watch all namespaces Expected results: Should add an option to display the exact version info. For example, we can add "version" option to display the version info from the GitHub. Additional info:
The binaries now include `version` subcommands, so that `catalog version` and `olm version` output the semver and git sha.
I'm sorry, but I still could not find the version info about the catalog and the olm themselves. I used image: registry.reg-aws.openshift.com:443/openshift3/ose-operator-lifecycle-manager:v3.11 imageID: docker-pullable://registry.reg-aws.openshift.com:443/openshift3/ose-operator-lifecycle-manager@sha256:b3656f79465c21b0843739dbe3456fadeabfcaf3014551f85cb91f57da559948 [root@qe-juzhao-311-gce-1-master-etcd-1 ~]# oc get pods NAME READY STATUS RESTARTS AGE alm-operator-7bccff7988-8hqxm 1/1 Running 0 2h catalog-operator-f655bccb9-rkdm2 1/1 Running 0 2h [root@qe-juzhao-311-gce-1-master-etcd-1 ~]# oc rsh alm-operator-7bccff7988-8hqxm sh-4.2$ olm version INFO[0000] Using in-cluster kube client config INFO[0000] Using in-cluster kube client config INFO[0001] connection established. cluster-version: v1.11.0+d4cacc0 INFO[0001] Operator ready INFO[0001] starting informers... INFO[0001] waiting for caches to sync... INFO[0001] openshift-console/console added INFO[0001] openshift-monitoring/cluster-monitoring-operator added INFO[0001] openshift-monitoring/grafana added INFO[0001] openshift-monitoring/kube-state-metrics added INFO[0001] openshift-monitoring/prometheus-operator added ... sh-4.2$ catalog version INFO[0000] Using in-cluster kube client config INFO[0000] Using in-cluster kube client config INFO[0000] connection established. cluster-version: v1.11.0+d4cacc0 INFO[0000] Operator ready INFO[0000] starting informers... INFO[0000] waiting for caches to sync... INFO[0000] default/etcd-d8674 added INFO[0000] starting workers... INFO[0000] getting from queue key=default/etcd-d8674 queue=subscription INFO[0000] syncing channel=alpha namespace=default pkg=etcd source=rh-operators sub=etcd-d8674 INFO[0000] skipping sync: no new updates to catalog since last sync at 2018-09-11 05:24:49 +0000 UTC sh-4.2$ catalog --version flag provided but not defined: -version Usage of catalog: -alsologtostderr log to standard error as well as files -debug use debug log level -interval duration wakeup interval (default 15m0s) -kubeconfig string absolute path to the kubeconfig file -log_backtrace_at value when logging hits line file:N, emit a stack trace -log_dir string If non-empty, write log files in this directory -logtostderr log to standard error instead of files -namespace string namespace where catalog will run and install catalog resources (default "tectonic-system") -stderrthreshold value logs at or above this threshold go to stderr -v value log level for V logs -vmodule value comma-separated list of pattern=N settings for file-filtered logging -watchedNamespaces string comma separated list of namespaces that catalog watches, leave empty to watch all namespaces sh-4.2$ catalog -version flag provided but not defined: -version Usage of catalog: -alsologtostderr log to standard error as well as files -debug use debug log level -interval duration wakeup interval (default 15m0s) -kubeconfig string absolute path to the kubeconfig file -log_backtrace_at value when logging hits line file:N, emit a stack trace -log_dir string If non-empty, write log files in this directory -logtostderr log to standard error instead of files -namespace string namespace where catalog will run and install catalog resources (default "tectonic-system") -stderrthreshold value logs at or above this threshold go to stderr -v value log level for V logs -vmodule value comma-separated list of pattern=N settings for file-filtered logging -watchedNamespaces string comma separated list of namespaces that catalog watches, leave empty to watch all namespaces
I didn't realize master had switched to 4.0. I'll need to cherry pick this (and several other changes) to 3.11
Apparently brew/osbs is having problems with 3.11 builds, so the newest containers may not have this code in them yet.
This is merged whenever the build system actually picks it up and updates the images.
Evan, I can get the version info now, but, I could not find the git commit info(04ea8f2) in tag 0.6.0, or what does it mean? Can you help post the fixed PR in here? Change status to "ASSIGNED" first. [root@qe-juzhao-311-gce-1-master-etcd-1 ~]# oc get pods NAME READY STATUS RESTARTS AGE catalog-operator-76c846684c-l54mt 1/1 Running 0 1h olm-operator-5b7f7c4556-f2l7p 1/1 Running 0 1h [root@qe-juzhao-311-gce-1-master-etcd-1 ~]# oc rsh catalog-operator-76c846684c-l54mt ... sh-4.2$ catalog -version OLM version: 0.6.0 git commit: 04ea8f2 sh-4.2$ olm -version OLM version: 0.6.0 git commit: 04ea8f2 OLM image info: registry.reg-aws.openshift.com:443/openshift3/ose-operator-lifecycle-manager:v3.11 imageID: docker-pullable://registry.reg-aws.openshift.com:443/openshift3/ose-operator-lifecycle-manager@sha256:9ad55d4ba475980cbb2f3b7799e05c6a4f0570fd3589bfd122f836255a7160cc
0.6.0 means that the version string set in the repo here: https://github.com/operator-framework/operator-lifecycle-manager/blob/master/OLM_VERSION It doesn't correspond to git tags, at least not yet. The git commit is the current HEAD of the git repo that the container is built from. We set it here: https://github.com/operator-framework/operator-lifecycle-manager/blob/master/Makefile#L49
Evan, I don't think it's a good way to address this issue. It's confusing for users. It's difficult for users to check the exact commit info. For example, how to know the details info(such as, which PR merged in) from the commit "0c87d85"? [root@share-wmenghaglb3116-mez-1 ~]# oc rsh olm-operator-5b7f7c4556-jcwlt sh-4.2$ olm -version OLM version: 0.6.0 git commit: 0c87d85 I suggest that we use the git tag to trace the version and remove the git commit info. Because users can get the commit info from the git tag.
Git tags are mutable and unrelated to the content, the commit sha will never will change (it could be force-removed from a repo, though) For example, you can do `git log 0c87d85` with the commit sha above and see exactly which commits went into the build.
Evan, 1, Could you help post the detail steps to check the commit info? I did the following steps but got nothing. [root@qe-jiazha-master-etcd-1 ~]# oc rsh catalog-operator-76c846684c-kv8mj sh-4.2$ olm -version OLM version: 0.6.0 git commit: 3df6bea [root@localhost operator-lifecycle-manager]# pwd /home/jzhang/goproject/src/github.com/operator-framework/operator-lifecycle-manager [root@localhost operator-lifecycle-manager]# git branch * master release-3.11 so, which git repo the commit "3df6bea" belongs to? I could not find it in the https://github.com/operator-framework/operator-lifecycle-manager repo. [root@localhost operator-lifecycle-manager]# git log 3df6bea fatal: ambiguous argument '3df6bea': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' The latest commit: [root@localhost operator-lifecycle-manager]# git log commit 678fea44cfea340f798b8aa629aa8f388a32b66f Merge: 46ce377 d808bcc Author: Evan Cordell <cordell.evan> Date: Mon Sep 17 13:14:48 2018 -0400 Merge pull request #464 from operator-framework/add-owners Create OWNERS 2, As you know, the latest version of OLM is 0.7.0 (https://github.com/operator-framework/operator-lifecycle-manager/blob/master/OLM_VERSION) but the version info is still 0.6.0, what's wrong here? Which git repo the image built from? https://github.com/operator-framework/operator-lifecycle-manager?
The containers that ship in openshift are stored in dist-git: # git clone git://pkgs.devel.redhat.com/containers/operator-lifecycle-manager and specifically the rhaos-3.11-rhel-7 branch. It gets synced from `release-3.11` branch on github. The master branch on github has moved on to 0.7.0 as you pointed out, but we froze 3.11 so that our updates for 4.0 don't affect this release. IMO, the automated tooling that syncs into dist-git shouldn't build from commits that aren't in the upstream repo (github), but apparently that's not how it's done right now.
Evan, sh-4.2$ olm -version OLM version: 0.6.0 git commit: 3df6bea As a customer, I could not find the exact commit info from the "git commit: 3df6bea" provided by the command "olm -version" since I cannot access the dist-git. And, it's difficult for users to check the PR info from the "OLM version: 0.6.0" info provided by the "olm -version". In other words, the "-version" option has no meaning in this way. I think the output of the "olm -version" should contain the commit info from the upstream github repo so that user can check the commit info they cared about.
I agree that there should be a way to find out what commits are being used. Unfortunately ART does not preserve our git history in a way that is sensible for users. Since this isn't a blocker for 3.11, I'm moving to 3.11.z. How are other components solving this?
Evan, I'm sorry, but I am not very clear about this. Below is the version info of service-catalog for your reference. the "v0.1.31" info against the upstream tag branch. [root@preserve-share3-wmeng-master-etcd-1 ~]# oc rsh controller-manager-5zff8 sh-4.2$ service-catalog --version v3.11.9;Upstream:v0.1.31 @Jay Can you help clarify how the "--version" option works? Many thanks!
Jeff Peeler did the work for Service Catalog to report the upstream version - - and it's actually a manually process when we rebase Upstream into OpenShift (update a text file that contains the upstream version). Completely manual but its a huge help to have the mapping reported in the log or by --version.
Jay, Thanks for your information! Yes, it's a great help! @Evan, > Completely manual but its a huge help to have the mapping reported in the log or by --version. Maybe we can follow this solution. Change the status to "ASSIGNED" since the current version info is not quite useful. [root@qe-jiazha-master-etcd-1 ~]# oc rsh catalog-operator-76c846684c-dnrpl sh-4.2$ olm -version OLM version: 0.6.0 git commit: c3641a6
It's debatable as to what git commit should be returned for dist-git built images and I'm going to ignore that for now. For 4.0 images, it looks like you can get the upstream git commit the image was created from by examining the image labels. Specifically in this case I'd try looking at what io.openshift.source-repo-commit is set to: docker inspect -f '{{index .ContainerConfig.Labels "io.openshift.source-repo-commit" }}' <image SHA> Note that for the 4.0 origin images, the label is named differently ("io.openshift.source-repo-commit").
Thanks @Jeff > Note that for the 4.0 origin images, the label is named differently ("io.openshift.source-repo-commit") Yes, I could not find it so post the whole inspect info below: [core@jian-master-0 ~]$ sudo podman inspect beedab781249 [ { "Id": "beedab781249dd28082d908b2cb23c966d28cca9b16d61b3736cd7adb85d94d0", "Digest": "sha256:e8b5c6db432f1960e3b260a72797cd06f43f3781b3009a9abd2e069ac187f171", "RepoTags": [ "registry.svc.ci.openshift.org/openshift/origin-v4.0-20181128050751@sha256:e8b5c6db432f1960e3b260a72797cd06f43f3781b3009a9abd2e069ac187f171" ], "RepoDigests": [ "registry.svc.ci.openshift.org/openshift/origin-v4.0-20181128050751@sha256@sha256:e8b5c6db432f1960e3b260a72797cd06f43f3781b3009a9abd2e069ac187f171" ], "Parent": "", "Comment": "", "Created": "2018-11-27T03:38:50.869672004Z", "ContainerConfig": { "User": "1001", "ExposedPorts": { "5443/tcp": {}, "8080/tcp": {} }, "Env": [ "OPENSHIFT_BUILD_NAME=olm", "OPENSHIFT_BUILD_NAMESPACE=ci-op-t0jil199", "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" ], "Cmd": [ "/bin/bash" ], "Labels": { "io.k8s.description": "This is a component of OpenShift Container Platform and manages the lifecycle of operators.", "io.k8s.display-name": "OpenShift Operator Lifecycle Manager", "io.openshift.build.commit.author": "", "io.openshift.build.commit.date": "", "io.openshift.build.commit.id": "bb46d55c3d4ee769def963520c9892c76b48999c", "io.openshift.build.commit.message": "", "io.openshift.build.commit.ref": "master", "io.openshift.build.name": "", "io.openshift.build.namespace": "", "io.openshift.build.source-context-dir": "", "io.openshift.build.source-location": "https://github.com/operator-framework/operator-lifecycle-manager", "io.openshift.release.operator": "true", "io.openshift.tags": "openshift,base", "maintainer": "Odin Team <aos-odin>", "org.label-schema.build-date": "20181006", "org.label-schema.license": "GPLv2", "org.label-schema.name": "CentOS Base Image", "org.label-schema.schema-version": "1.0", "org.label-schema.vendor": "CentOS", "vcs-ref": "bb46d55c3d4ee769def963520c9892c76b48999c", "vcs-type": "git", "vcs-url": "https://github.com/operator-framework/operator-lifecycle-manager" } }, "Version": "1.13.1", "Author": "", "Architecture": "amd64", "Os": "linux", "Size": 342966810, "VirtualSize": 342966810, "GraphDriver": { "Name": "overlay", "Data": { "LowerDir": "/var/lib/containers/storage/overlay/6805591d807a8eaa370c7c75e361d558997b86d63783ba7cd07ad824ece78552/diff:/var/lib/containers/storage/overlay/f972d139738dfcd1519fd2461815651336ee25a8b54c358834c50af094bb262f/diff", "MergedDir": "/var/lib/containers/storage/overlay/e0652e76437d3ba376d93e11dd448e82502af8eabc7b390dda2ef1a8e388ff05/merged", "UpperDir": "/var/lib/containers/storage/overlay/e0652e76437d3ba376d93e11dd448e82502af8eabc7b390dda2ef1a8e388ff05/diff", "WorkDir": "/var/lib/containers/storage/overlay/e0652e76437d3ba376d93e11dd448e82502af8eabc7b390dda2ef1a8e388ff05/work" } }, "RootFS": { "Type": "layers", "Layers": [ "sha256:f972d139738dfcd1519fd2461815651336ee25a8b54c358834c50af094bb262f", "sha256:45583df323451139f50c8ace226d87105624c9125a65ee2b715ebc9d4244f07a", "sha256:7c955acf6d62be5419735590d9696eeefe6eeec34c9099266d3982dd0fb99151" ] }, "Labels": { "io.k8s.description": "This is a component of OpenShift Container Platform and manages the lifecycle of operators.", "io.k8s.display-name": "OpenShift Operator Lifecycle Manager", "io.openshift.build.commit.author": "", "io.openshift.build.commit.date": "", "io.openshift.build.commit.id": "bb46d55c3d4ee769def963520c9892c76b48999c", "io.openshift.build.commit.message": "", "io.openshift.build.commit.ref": "master", "io.openshift.build.name": "", "io.openshift.build.namespace": "", "io.openshift.build.source-context-dir": "", "io.openshift.build.source-location": "https://github.com/operator-framework/operator-lifecycle-manager", "io.openshift.release.operator": "true", "io.openshift.tags": "openshift,base", "maintainer": "Odin Team <aos-odin>", "org.label-schema.build-date": "20181006", "org.label-schema.license": "GPLv2", "org.label-schema.name": "CentOS Base Image", "org.label-schema.schema-version": "1.0", "org.label-schema.vendor": "CentOS", "vcs-ref": "bb46d55c3d4ee769def963520c9892c76b48999c", "vcs-type": "git", "vcs-url": "https://github.com/operator-framework/operator-lifecycle-manager" }, "Annotations": {}, "ManifestType": "application/vnd.docker.distribution.manifest.v2+json", "User": "1001" } ] OC version: [core@jian-master-0 ~]$ oc version oc v4.0.0-alpha.0+a768c47-662 kubernetes v1.11.0+d4cacc0 features: Basic-Auth GSSAPI Kerberos SPNEGO Server https://jian-api.tt.testing:6443 kubernetes v1.11.0+d4cacc0 The current OLM version: [core@jian-master-0 ~]$ oc get pods NAME READY STATUS RESTARTS AGE catalog-operator-6845f75dbc-ttpfw 1/1 Running 1 15h olm-operator-796dc97869-st84w 1/1 Running 1 15h package-server-65db98fcc5-r7r99 1/1 Running 1 15h [core@jian-master-0 ~]$ oc exec olm-operator-796dc97869-st84w -- olm -version OLM version: 0.8.0 git commit: bb46d55
Sorry, I didn't copy/paste correctly. The 4.0 images use the label "io.openshift.build.commit.id". vcs-ref seems to be valid too and shorter to type.
Jeff, Yes, thanks! For 4.0, the output of the `olm -version` as expected. For example, [core@ip-10-0-2-239 ~]$ oc exec olm-operator-bd856dcb7-wn9d4 -- olm -version OLM version: 0.8.0 git commit: 02bf679 [core@ip-10-0-2-239 ~]$ sudo podman inspect -f '{{index .ContainerConfig.Labels "io.openshift.build.commit.id" }}' 5cd2cc0c019c 02bf6794225f042f2583d3af3ed31854d801c549 The commit id "02bf679" align with the https://github.com/operator-framework/operator-lifecycle-manager/commit/02bf6794225f042f2583d3af3ed31854d801c549 The users can get the merged PR info clearly.
*** This bug has been marked as a duplicate of bug 1662263 ***
Evan, One question, this bug reported for OCP 3.11. Based on my understanding, we should preserve it unless we don't intend to fix it for 3.11.