Will fix next sprint

The binaries are part of the `cli-artifacts` image. 
Check -> https://github.com/openshift/console-operator/blob/master/manifests/07-downloads-deployment.yaml#L36
Assigning to Release team.

It would be helpful if you would include the output, because I think it's a bit more specific, like:

$ ./oc version
Client Version: openshift-clients-4.4.0-202006211643.p0-2-gd89e458c3

Console client downloads do indeed come from the cli-artifacts image, and so they'll have the same version as that image. If you fire up the cli-artifacts image for your release and run oc in it, you should get the same answer as the console download gives.

For 4.1-4.3 that will be something like
openshift-clients-4.y.z-timestamp-etc
where 4.y.z is close to (but not necessarily the same as) the release that is running on the server.

For 4.4+ we changed component versioning, so that will be something like
openshift-clients-4.y.0-timestamp-etc
in other words, the .z is always 0, just like the version of the cli-artifacts image itself if you look at the labels.

So:

> Server is 4.5.2 and binary is 4.6.0

That should not be possible. I agree the downloaded binary says it is 4.6.0 but surely the console is actually not 4.5.2. 

$ podman run $(oc adm release info --image-for cli-artifacts quay.io/openshift-release-dev/ocp-release:4.5.2-x86_64) oc version
Trying to pull quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:9747fa3e6df23546bc64cc38b371ce3219e94137feb315513469346e9c11e307
[...]
Client Version: openshift-clients-4.5.0-202006231303.p0-2-g592b16566

If what you have deployed there is a 4.5.2 cluster then we really screwed up something in that release. Please check.

> Server is 4.4.12 and binary is 4.4.0
> Server is 4.5.3 and binary is 4.5.0
> Server is 4.4.13 and binary is 4.4.0

All as expected.

I started a 4.5.2 cluster and checked the downloaded oc version - it was openshift-clients-4.6.0-202005210021-30-g592b16566. I really don't understand how that's possible, seems like a console bug since as noted above the version in cli-artifacts is correct. Since it seems fixed in more recent versions I don't know if the console team feels a need to follow up, but I'll pass it to them in case they'd like to investigate how this happened.

Otherwise this seems like NOTABUG to me.

@Luke thanks for the explanation. I have been out of the office but and that's why I didn't answered yet.

Please see next questions:
 - why can't the image just ship the same binaries than the ones in https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$VERSION/openshift-client-linux-$VERSION.tar.gz? 
 - Why the same binary if downloaded from the console or the mirror does the same but reports different versions?
 - Why this isn't properly documented?
 - Is there any reference table to match the content downloaded from mirror.oepsnhift.com with the content downloaded from the console?

(In reply to Sergio G. from comment #5)
I'll note first that there were a lot of discussions around this when we were first getting ready to ship OCP 4, and there was no simple solution. (You haven't mentioned how the clients on the portal are completely different, and required for mac/windows :)

>  - why can't the image just ship the same binaries than the ones in
> https://mirror.openshift.com/pub/openshift-v4/clients/ocp/$VERSION/openshift-
> client-linux-$VERSION.tar.gz? 
>  - Why the same binary if downloaded from the console or the mirror does the
> same but reports different versions?

Actually... it _is_ the same binary, with just the reported version tweaked. The release process uses `oc adm release extract --tools` to get the same binary from the cli-artifacts; it's just that the extraction process rewrites the version to match the release image version (e.g. "4.5.2"). I think this may be clearer if it didn't. This would require a change to the oc client.

>  - Why this isn't properly documented?

I don't know. Where would you expect to find it documented?

>  - Is there any reference table to match the content downloaded from
> mirror.oepsnhift.com with the content downloaded from the console?

No, there isn't... the simplest way would be to query the relevant release image. So if you're looking for "what console client version corresponds to http://mirror.openshift.com/pub/openshift-v4/clients/ocp/4.5.2/" you could:

oc image info $(oc adm release info --image-for cli-artifacts quay.io/openshift-release-dev/ocp-release:4.5.2-x86_64) | grep -E 'OS_GIT_VERSION|SOURCE_GIT_TAG'
             OS_GIT_VERSION=4.5.0-202007131801.p0-592b165
             SOURCE_GIT_TAG=openshift-clients-4.6.0-202005210021-30-g592b16566

OS_GIT_VERSION is the internal component version; SOURCE_GIT_TAG comes from the source github repository. Looking at this, I must have some faulty understanding since neither matches openshift-clients-4.6.0-202005210021-30-g592b16566 from the console or openshift-clients-4.5.0-202006231303.p0-2-g592b16566 from running the client in the image.

Thanks Luke for the explanation.

I totally understand what you say but I still consider it confusing for whoever uses the product (let's say 4.4.11), downloads the binary from the UI, runs "oc version" and gets a "openshift-clients-4.4.0-202006211643.p0-2-gd89e458c3" for the client instead of just "4.4.11".

While I would agree to consider this bugzilla to be closed as NOTABUG (as what customer gets is what we expected) I would ask before for a change in the UI console code or documentation to reflect the fact that the version string of the downloaded binary wont match exactly the version running in the server. A simple text like "Note that the binary downloaded from the UI will report a different version based on the source code revision system rather than the server version". That wont prevent complains (as the behavior is weird and difficult to argue on its favor) but will be there as an warning. What do you think?

On the other hand, I'm filling a separated RFE to try to get this changed so the binary version aligns with the server version.

> A simple text like "Note that the binary downloaded from the UI will report a different version based on the source code revision system rather than the server version"

I feel like the proposed text raises more questions than it answers. To be honest, I'm not totally sure what it is saying.

Console is merely serving the download as-is from cli-artifacts. Comment #6 also indicates that this is not a console bug. I'm not sure what the right component is, but I don't think it's the console team who should decide if this can be fixed.

I'm assigning back to the Release component for now. Luke, if you feel this needs to be fixed in the CLI, feel free to reassign.

>> I feel like the proposed text raises more questions than it answers. To be honest, I'm not totally sure what it is saying.

Customer is already asking why the version of their OpenShift is 4.4.11 and why the client that they download is 4.4.0-202006211643.p0-2-gd89e458c3. So I think that any text which clarifies the situation (as seems there's no willingness to align them) will help.

*** Bug 1868224 has been marked as a duplicate of this bug. ***

*** Bug 1914286 has been marked as a duplicate of this bug. ***

This was discussed yesterday on slack, the quick and simple solution is to have

oc image extract --serve option available.

Why is it so difficult to "just" add the content from mirror.openshift.com?
e.g. https://mirror.openshift.com/pub/openshift-v4/clients/ocp/${OCP-VERSION}/openshift-client-linux-${OCP-VERSION}.tar.gz
e.g. https://mirror.openshift.com/pub/openshift-v4/clients/opm/4.6.1/opm-linux-4.6.1.tar.gz

There should be also the other cmd line tool such as opm, grpcurl, virtctl, etc...
This would ease up the life of the customers on disconnected installations!

(In reply to Lars Bohnsack from comment #31)
> Why is it so difficult to "just" add the content from mirror.openshift.com?

This won't work with disconnected and air-gapped environments and we support both equally.

I meant push the available bits from mirror.openshift.com into the downloads pods...
I also do not understand why the uncompressed executables 'oc' and 'oc.exe' are compressed (tar, zip) and moved inside the pod while the pod starts... from my point of view this is wasting resources... even it's not that much

So the question is "Why not providing the bits from mirror.openshift.com into the download pod as they are?"
e.g. for 4.6.22
openshift-client-linux-4.6.22.tar.gz
openshift-client-mac-4.6.22.tar.gz
opm-linux-4.6.22.tar.gz
opm-mac-4.6.22.tar.gz
opm-windows-4.6.22.tar.gz
...

btw the helm and odo links are pointing to mirror.openshift.com ...

virtctl should also be available via the download pods (especially for the disconnected and air-gapped guys!)

(In reply to Luke Meyer from comment #6)
> Actually... it _is_ the same binary, with just the reported version tweaked.
> The release process uses `oc adm release extract --tools` to get the same
> binary from the cli-artifacts; it's just that the extraction process
> rewrites the version to match the release image version (e.g. "4.5.2"). I
> think this may be clearer if it didn't. This would require a change to the
> oc client.

For folks looking for links into the 'oc adm release extract ...' version-replacement code, [1] talks over the early history with links to commits.  Dropping this version-replacement seems like it might cause confusion ("I extracted oc from a 4.99.4 release image and got a 4.99.2 version of oc?  Am I missing some bugfixes?").

The current console-downloads code, in contrast, does no version replacement [2].  Comment 30's --serve (although I expect Maciej meant 'oc adm release extract --serve', to give it release-image awareness) would be one way to get version-replacement into the downloads pod.  Or someone could teach download's existing Python server how to do version injection.  Lots of possibilities.  Nothing that seems like it would be something folks could bang out quickly.

[1]: https://github.com/openshift/oc/pull/165#issue-523804074
[2]: https://github.com/openshift/console-operator/blob/90a6cbb4161a81709e78efde9b44085c37647318/bindata/deployments/downloads-deployment.yaml#L131-L134

This is going to be fixed in the long run when we implement https://github.com/openshift/enhancements/blob/master/enhancements/oc/cli-manager.md
which will be using the same mechanism as oc adm release which is responsible for replacing the oc internal version. 
Currently when you download the oc from web console it just serves the raw binary as it's packaged in the image,
whereas oc adm release extract can properly replace the version to match the server version. 
But the binary itself is the same, only version differs.

Dear Machiej,

Could you let us know how to check which oc-4.y.0-202XXXXXXXX binary equals to which oc-4.y.z binary?

In the case when user downloaded oc-4.y.0-202XXXXXXXX binary from OpenShift Web Console, it would be easy for user to guess the oc binary equals to which oc-4.y.z binary.
(Since the version would equal to the version of their OpenShift cluster)

However, user can install oc-4.y.0-202XXXXXXXX from yum repository.
Many oc-4.y.0-202XXXXXXXX binaries have been published on yum repository as follows. How can user check which one equals to which oc-4.y.z binary?

  #  yum list --show-duplicate openshift-clients
  ...
  Available Packages
  openshift-clients.x86_64           4.10.0-202202160023.p0.gf93da17.assembly.stream.el7            rhel-7-server-ose-4.10-rpms
  openshift-clients.x86_64           4.10.0-202203141248.p0.g6db43e2.assembly.stream.el7            rhel-7-server-ose-4.10-rpms
  openshift-clients.x86_64           4.10.0-202203170916.p0.g6de42bd.assembly.stream.el7            rhel-7-server-ose-4.10-rpms
  openshift-clients.x86_64           4.10.0-202203271029.p0.g346b183.assembly.stream.el7            rhel-7-server-ose-4.10-rpms
  openshift-clients.x86_64           4.10.0-202204011138.p0.g3e24949.assembly.stream.el7            rhel-7-server-ose-4.10-rpms
  openshift-clients.x86_64           4.10.0-202204291519.p0.g09f825e.assembly.stream.el7            rhel-7-server-ose-4.10-rpms

Best Regards,
Masaki Hatada

You can match the git sha of both, iow. oc version -oyaml will give you detailed information about the build such as:

clientVersion:
  buildDate: "2022-04-01T12:50:15Z"
  compiler: gc
  gitCommit: 3e24949fea37244367d50a1f3a226ec20d51eef1
  gitTreeState: clean
  gitVersion: 4.10.0-202204011138.p0.g3e24949.assembly.stream-3e24949
  goVersion: go1.17.5
  major: ""
  minor: ""
  platform: linux/amd64

the gitCommit field should match on both binaries.

Dear Maciej,

Thank you for your update.

> You can match the git sha of both, iow. oc version -oyaml will give you detailed information about the build such as:

Just to run "oc version" command, customers need to download oc-4.10.x from mirror.openshift.com and install it to our machine.
It's an annoying task.

If it will take a long time to unify binary name of oc-4.10.x and oc-4.10.0-xxx, could Red Hat show the git version of oc-4.10.x in https://mirror.openshift.com/pub/openshift-v4/clients/ocp/4.10.4/release.txt ?

Best Regards,
Masaki Hatada

By the way, the git version of oc-4.10.x seems not to match to any openshift-clients package published on yum repository.

As far as I checked https://ftp.redhat.com/pub/redhat/linux/enterprise/7Server/en/RHOSE/SRPMS/ , the following packages have been released on yum repository server.
- openshift-clients-4.10.0-202202160023.p0.gf93da17
- openshift-clients-4.10.0-202203141248.p0.g6db43e2
- openshift-clients-4.10.0-202203170916.p0.g6de42bd
- openshift-clients-4.10.0-202203271029.p0.g346b183
- openshift-clients-4.10.0-202204011138.p0.g3e24949
- openshift-clients-4.10.0-202204291519.p0.g09f825e

On the other hand, the git version of oc-4.10.4 binary is 4.10.0-202203081809.p0.gf93da17.
It doesn't match to any git version of the above packages.

$ oc version --client
Client Version: 4.10.4
$ oc version --client -ojson | jq -rM ".clientVersion.gitVersion"
4.10.0-202203081809.p0.gf93da17.assembly.stream-f93da17

Doesn't Red Hat provide the same binary on mirror.openshift.com and yum repository?

gitVersion is longer, that's why I proposed gitCommit ;-)

> gitVersion is longer, that's why I proposed gitCommit ;-)

Oh, sorry. 
But how can check which oc-4.10.x matches to which oc-4.10.0-xxx by this gitCommit value?

$ oc version --client -ojson | jq -rM ".clientVersion.gitCommit"
f93da179fe606775f8249fed96e0b9903d9188ed

Does we need to download/install each openshift-clients-4.10.0-xxx packages one by one and run "oc version" command?

(In reply to Masaki Hatada from comment #51)
> > gitVersion is longer, that's why I proposed gitCommit ;-)
> 
> Oh, sorry. 
> But how can check which oc-4.10.x matches to which oc-4.10.0-xxx by this
> gitCommit value?
> 
> $ oc version --client -ojson | jq -rM ".clientVersion.gitCommit"
> f93da179fe606775f8249fed96e0b9903d9188ed
> 
> Does we need to download/install each openshift-clients-4.10.0-xxx packages
> one by one and run "oc version" command?

Unfortunately that's the only reliable way to tell the difference :(

Dear Maciej,

Thank you for your reply.

> Unfortunately that's the only reliable way to tell the difference :(

So I would like to return to the story written in Comment 48.

If it will take a long time to unify binary name of oc-4.10.x and oc-4.10.0-xxx, could Red Hat write gitVersion and gitCommmit of oc-4.10.x in https://mirror.openshift.com/pub/openshift-v4/clients/ocp/<OpenShift version>/release.txt?

Currently there is no easy way to know which oc-4.10.x matches to oc-4.10.0-xxx.
It would be a big help if user can check gitVersion and gitCommmit of oc-4.10.x from release.txt.

Best Regards,
Masaki Hatada

(In reply to Masaki Hatada from comment #53)
> Dear Maciej,
> 
> Thank you for your reply.
> 
> > Unfortunately that's the only reliable way to tell the difference :(
> 
> So I would like to return to the story written in Comment 48.
> 
> If it will take a long time to unify binary name of oc-4.10.x and
> oc-4.10.0-xxx, could Red Hat write gitVersion and gitCommmit of oc-4.10.x in
> https://mirror.openshift.com/pub/openshift-v4/clients/ocp/<OpenShift
> version>/release.txt?

That sounds like a reasonable solution, I'd need to check the code what's possible.

Dear Fukumoto-san,

Could you let us know why it was closed without fix?
This version inconsistency has caused confusions on multiple customers many times.
It must be fixed.

Red Hat changed this priority and severity to high at 2023-01-03. So we don't know why it was closed without fix.

Best Regards,
Masaki Hatada

Hello,

This bug was closed due to the following comment:

 > We no longer track bugs in Bugzilla. Please consider moving the issue to Jira.

We need to file a new bug in Jira.

--
Hideshi Fukumoto

Dear Fukumoto-san,

Thank you for the reply.

Could you file a new bug in JIRA instead of us?
Since to migrate from bugzilla to JIRA is an internal task of Red Hat.

It must be handled in Red Hat side.

Best Regards,
Masaki Hatada

Dear Hatada-san, and all relevant RH members,

I cloned this on behalf of Fukumoto-san.
We will continue our discussion in the new Jira.
PS: Since the original BZ(1862377) was public level, so I made Jira public as well.

https://issues.redhat.com/browse/OCPBUGS-7362

Best Regards,
Kazuhisa Hara