Bug 1662263 - The binary version inside the OLM 4.0 downstream image is not quite useful
Summary: The binary version inside the OLM 4.0 downstream image is not quite useful
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: OLM
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.2.0
Assignee: Evan Cordell
QA Contact: Jian Zhang
URL:
Whiteboard:
: 1626434 (view as bug list)
Depends On:
Blocks: 1753394
TreeView+ depends on / blocked
 
Reported: 2018-12-27 09:01 UTC by Jian Zhang
Modified: 2019-10-16 06:27 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-16 06:27:41 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github operator-framework operator-lifecycle-manager pull 961 0 'None' 'closed' 'Bug 1662263: include git sha in ART builds' 2019-12-04 20:53:20 UTC
Red Hat Product Errata RHBA-2019:2922 0 None None None 2019-10-16 06:27:56 UTC

Comment 2 Jian Zhang 2019-01-04 01:53:18 UTC
Evan,

> The git commit matches the git repo that the image was built from. For OSE, that means the commit in the dist-git repo.
> You can use it to trace it to the code that was actually used to build the image.

Yeah, but as an end user, how can they trace the code according to the build commit info?
It would be better if we let the downstream image output the PR commit info as we did for the upstream image.
I guess this is quite similar to bug 1626434.

Comment 10 Jian Zhang 2019-01-31 03:23:01 UTC
Tim

> Try inspecting the image itself directly.

Yes, thanks, I know. I described it in comment 7. But, the customer could get the auth of the image registry?

Luke,

> however I'm not sure how to feel about putting it in *all* the images we build.

Yeah, understood. But, I think the customer prefers the source commits as the "olm --version" output. Because the dist-git commits make no sense for them.
I insist the better user experience is the first. I think we should address this issue. We can delay it to the 4.1 if we cannot address it in 4.0.

Comment 11 Tim Bielawa 2019-01-31 15:09:26 UTC
(In reply to Jian Zhang from comment #10)
> Tim
> 
> > Try inspecting the image itself directly.
> 
> Yes, thanks, I know. I described it in comment 7. But, the customer could
> get the auth of the image registry?

My mistake, I missed that comment.

> Luke,
> 
> > however I'm not sure how to feel about putting it in *all* the images we build.
> 
> Yeah, understood. But, I think the customer prefers the source commits as
> the "olm --version" output. Because the dist-git commits make no sense for
> them.

That's correct, they would not make any sense to them.

> I insist the better user experience is the first. I think we should address
> this issue. 

You're absolutely right. From a customer standpoint it is simply confusing and misleading.

> We can delay it to the 4.1 if we cannot address it in 4.0.

I think 4.1 will be realistic. We need to create a card for this so we don't lose track of the work. I will add one to our backlog presently.

Comment 12 Tim Bielawa 2019-01-31 15:48:32 UTC
Card is here https://jira.coreos.com/browse/ART-465 filling details this morning.

Comment 13 Tim Bielawa 2019-01-31 16:39:30 UTC
Wrong card, this is your card: https://jira.coreos.com/browse/ART-460

Comment 14 Jian Zhang 2019-02-01 03:07:46 UTC
Tim,

Many thanks for your understanding! I change the Target Release to "4.1.0". Correct me if I'm wrong.

Comment 15 Tim Bielawa 2019-02-04 14:50:09 UTC
(In reply to Jian Zhang from comment #14)
> Tim,
> 
> Many thanks for your understanding! I change the Target Release to "4.1.0".
> Correct me if I'm wrong.

That's perfect Jian. And thanks for sending us this bug. It'll improve the overall product when we can start working on a fix :-)

Comment 16 Evan Cordell 2019-02-28 16:17:16 UTC
*** Bug 1626434 has been marked as a duplicate of this bug. ***

Comment 17 Jessica Forrester 2019-03-29 19:38:41 UTC
This experience will be improved by ART processes in https://jira.coreos.com/browse/ART-460

Comment 18 Jian Zhang 2019-04-02 03:13:25 UTC
Reopen it since we should have a bug in BZ to trace this issue.

Comment 24 Jian Zhang 2019-07-29 05:24:58 UTC
Looks good to me, verify it, thanks all!

Cluster version is 4.2.0-0.nightly-2019-07-28-222114

We can see, the git commit is `d2209c409b35f1db4669c474044decc6995f624d`, and it does from the code source commits of OLM: https://github.com/operator-framework/operator-lifecycle-manager/commits/master

mac:~ jianzhang$ oc exec catalog-operator-86f77c9666-2c5nk -- olm --version
OLM version: 0.11.0
git commit: d2209c409b35f1db4669c474044decc6995f624d

We can also get the details by using `git show` under OLM git repo, as below:
mac:operator-lifecycle-manager jianzhang$ git show d2209c409b35f1db4669c474044decc6995f624d
commit d2209c409b35f1db4669c474044decc6995f624d (HEAD -> master, origin/master, origin/HEAD)
Merge: cd86d42b a624aaec
Author: OpenShift Merge Robot <openshift-merge-robot.github.com>
Date:   Fri Jul 26 23:04:36 2019 +0200

    Merge pull request #967 from tkashem/changelog
    
    (release) update changelog

mac:operator-lifecycle-manager jianzhang$ git branch
  fix-provider
* master

Comment 26 errata-xmlrpc 2019-10-16 06:27:41 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2922


Note You need to log in before you can comment on or make changes to this bug.