Bug 1658957 - Should support openshift version endpoint in 4.0 nextgen env like BYOH env
Summary: Should support openshift version endpoint in 4.0 nextgen env like BYOH env
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Master
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.1.0
Assignee: Michal Fojtik
QA Contact: Xingxing Xia
URL:
Whiteboard:
: 1673258 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-13 09:10 UTC by Xingxing Xia
Modified: 2019-03-12 14:24 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-01-02 14:55:15 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1353355 0 unspecified CLOSED RFE: Show Master Version in the Output of oc version 2021-02-22 00:41:40 UTC

Description Xingxing Xia 2018-12-13 09:10:22 UTC
Description of problem:
Using new bug for tracking https://bugzilla.redhat.com/show_bug.cgi?id=1621724#c2 .
In 4.0 nextgen env, oc version doesn't have openshift server version shown.
It should support openshift version endpoint like 4.0 BYOH env.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Create 4.0 nextgen env
2. oc version # against nextgen env

Actual results:
2. No openshift server version is shown:
oc v4.0.0-0.95.0
kubernetes v1.11.0+8afe8f3cf9
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://***.devcluster.openshift.com:6443
kubernetes v1.11.0+9d2874f

Expected results:
2. It should support openshift version endpoint like 4.0 BYOH env:
$ oc version # against BYOH env
oc v4.0.0-0.94.0
kubernetes v1.11.0+3db990d20d
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://preserve-qe-lxia-40-master-etcd-1:8443
openshift v4.0.0-0.95.0
kubernetes v1.11.0+8afe8f3cf9

Additional info:
BTW, `hypershift openshift-kube-apiserver --version` does not return version as its help info. This should be fixed:
$ oc get pod -n openshift-kube-apiserver
openshift-kube-apiserver-ip-10-0-0-164.ec2.internal    1/1       Running     0          1d

$ oc rsh -n openshift-kube-apiserver openshift-kube-apiserver-ip-10-0-0-164.ec2.internal
sh-4.2# ps -eF
UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
root         1     0 14 371553 737728 0 Dec12 ?        04:17:51 hypershift openshift-kube-apiserver --config=...
sh-4.2# hypershift openshift-kube-apiserver -h | grep version
      --version version[=true]                       Print version information and quit
sh-4.2# hypershift openshift-kube-apiserver --version=true
Error: required flag(s) "config" not set

Comment 1 David Eads 2018-12-18 12:57:15 UTC
That endpoint will not be coming back.  Because the openshift-apiserver is aggregated behind the kube-apiserver, the idea of a /version/openshift no longer exists.  The kube-apiserver may support multiple skewed levels of openshift-apiserver behind it.

Comment 2 Aleksandar Kostadinov 2018-12-18 16:05:28 UTC
>   The kube-apiserver may support multiple skewed levels of openshift-apiserver behind it.

This is exactly the reason to request version reporting for OpenShift. If there would be multiple components, then it would be best to have these other components versions as well. There should be an easy way for users to know what version server is running. Even more so because client version should be close to server version to be supported.

As a user I'd definitely want *an easy way* to know what version of server (and other components) I'm running whether or not I'm a cluster administrator.

David, was this change discussed and approved officially? IIRC in the beginning of OpenShift 3.0 version was not reported. Then there was an API endpoint added where it started to be reported (maybe 3.2). I assume customers requested that at the time. Definitely QE always wanted an easy way to check version under testing. From your answer it sounds like nothing changed in a way that makes openshift version reporting unnecessary.

Please also consider testing staging and dedicated clusters where QE does *not* have administrative access. We always need to know OpenShift version when testing. And everybody requests automatic pipelines so all metadata should be automatically discoverable. Thus using separate channel to know cluster version and then supplying that manually to test executors is a non-option.

Comment 3 Xingxing Xia 2018-12-21 07:36:54 UTC
First, agree with Aleksandar.
Second, BTW for nextgen env there is `oc get clusterversion`, system:admin can run it:
# oc get clusterversion
NAME      VERSION                           AVAILABLE   PROGRESSING   SINCE     STATUS
version   4.0.0-0.alpha-2018-12-20-221917   True        False         1h        Cluster version is 4.0.0-0.alpha-2018-12-20-221917

Normal user cannot run it:
$ oc get clusterversion
No resources found.
Error from server (Forbidden): clusterversions.config.openshift.io is forbidden: User "xxia" cannot list clusterversions.config.openshift.io at the cluster scope: no RBAC policy matched
David, this should be a bug, normal user should be able to get clusterversion, right?

Third, ‵hypershift openshift-kube-apiserver --version=true` should be fixed:
(In reply to Xingxing Xia from comment #0)
> Additional info:
> BTW, `hypershift openshift-kube-apiserver --version` does not return version
> as its help info. This should be fixed:
> $ oc rsh -n openshift-kube-apiserver
> openshift-kube-apiserver-ip-10-0-0-164.ec2.internal
> sh-4.2# hypershift openshift-kube-apiserver -h | grep version
>       --version version[=true]                       Print version
> information and quit
> sh-4.2# hypershift openshift-kube-apiserver --version=true
> Error: required flag(s) "config" not set

Comment 15 Aleksandar Kostadinov 2019-01-04 18:49:12 UTC
For the record it was bug 1353355 where feature was initially implemented.

Comment 16 Clayton Coleman 2019-01-04 23:01:11 UTC
In 4.0, the correct way to get the version of the product is:

```
oc get clusterversion
```

or 

```
curl https://API/apis/v1/config.openshift.io/clusterversions/version 
```

and extract status.desired.version

Comment 19 Xingxing Xia 2019-02-14 10:57:18 UTC
*** Bug 1673258 has been marked as a duplicate of this bug. ***


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