search

janus-idp / operator

Deprecated - Operator for Backstage, based on the Operator SDK framework - see https://github.com/redhat-developer/rhdh-operator
https://github.com/redhat-developer/rhdh-operator
Apache License 2.0
14 stars 14 forks source link

Display operator version (including commit hash) #109

Closed rm3l closed 1 month ago

rm3l commented 8 months ago

User Story

As an administrator or support user, I want to have a way to quickly check which version of the operator code I am running in my cluster so that I can quickly troubleshoot potential issues. Just information about the Git commit hash could be helpful.

Acceptance Criteria

gazarenkov commented 8 months ago

@rm3l where exactly you want to see the version?

because we already have VERSION in the makefile and it is copied to CSV's version: 0.0.1 (0.0.2 for newer one)

rm3l commented 8 months ago

The VERSION in the Makefile does not seem sufficient to me, as it doesn't allow pinpointing exactly what we are running. I was thinking that displaying the Git commit hash as additional info could be helpful to troubleshoot issues. This could be displayed in the controller logs (and/or via an additional version subcommand).

gazarenkov commented 8 months ago

I think as a developer/QE you should know that and as an administrator you rather need to know the Released version upfront (that's why it is copied to CSV I guess) and support hardly will deal with unreleased version too. Did I miss something?

jianrongzhang89 commented 8 months ago

I also think having the version and git commit # in the logs helps developers to troubleshoot the issue.

rm3l commented 8 months ago

Whoops, I missed this comment 🤦🏿

I think as a developer/QE you should know that and as an administrator you rather need to know the Released version upfront (that's why it is copied to CSV I guess) and support hardly will deal with unreleased version too. Did I miss something?

I agree administrators should be aware of the released versions, but for developers iterating on unreleased code, that would be different. In our case, we had an issue with the build pipeline: a mismatch between the CSV version and the operator code. And this is what I wanted to avoid in the future, or at least provide a way to figure it out quicker than trying to reproduce it (which can be time-consuming). If the logs had the commit hash displayed, it would have been quicker to figure out what the issue was. I was thinking of the commit hash as additional information to display in the logs. This would help us and support people to quickly troubleshoot potential issues. This would be part of the first things to check when an issue is reported.

gazarenkov commented 8 months ago

Did I understand it correct: simply speaking, we are trying to simplify identification of the git state for the problematic build? (if so, could we make it clear in the original description?)

My understanding: the build script https://github.com/janus-idp/operator/blob/main/.github/workflows/pr-docker-build.yaml already put the identifier of PR and commit hash as a part of image tag, so as a result we have: https://quay.io/repository/janus/operator?tab=tags

Is not it sufficient to identify the code for debug the problem?

nickboldt commented 4 months ago

Downstream issue https://issues.redhat.com/browse/RHIDP-1432

Note that in RHDH operator bundle we have pinned digests, which point to the specific operator, hub, and postgres images used in the deployment.

We could do something similar upstream, but do we need it?

nickboldt commented 1 month ago

As part of the migration from janus-idp to redhat-developer in https://issues.redhat.com/browse/RHIDP-1021, this will not be done as it's already possible to use pinned digests in the downstream RHDH builds.

You can tell which operator you're running by looking at the CSV.