Bug 1471717 - oc version cannot get openshift version against ansible deployed service catalog env
Summary: oc version cannot get openshift version against ansible deployed service cata...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Service Broker
Version: 3.6.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 3.7.0
Assignee: Jeff Peeler
QA Contact: Xingxing Xia
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-17 10:12 UTC by Xingxing Xia
Modified: 2017-11-28 22:04 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
undefined
Clone Of:
Environment:
Last Closed: 2017-11-28 22:04:10 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:3188 normal SHIPPED_LIVE Moderate: Red Hat OpenShift Container Platform 3.7 security, bug, and enhancement update 2017-11-29 02:34:54 UTC

Internal Links: 1692670

Comment 1 Derek Carr 2017-07-17 14:55:30 UTC
target release for 3.7, as this should not block 3.6 release.

service catalog itself needs to report its own version.

https://github.com/kubernetes-incubator/service-catalog/issues/722

Comment 2 Aleksandar Kostadinov 2017-08-07 09:30:31 UTC
"this should not block 3.6 release" but it actually breaks our test framework which relies on version checks to execute properly.

Is there any workaround to restore the endpoint, even if it is a hack to make env respond properly? This will help us fix the issue during env installation and then our code can execute as normal.

Comment 3 Xingxing Xia 2017-09-19 06:09:25 UTC
> oc version against env started by `oc cluster up ... --service-catalog` has same problem
FYI, checked with v3.7.0-0.126.4 env of `oc cluster up ... --service-catalog`, it can return openshift version (Ansible env still depends on bug 1486623)

$ oc version
oc v3.7.0-0.126.4
kubernetes v1.7.0+80709908fd
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://master:8443
openshift v3.7.0-0.126.4
kubernetes v1.7.0+80709908fd

Not return `service catalog itself ... own version` mentioned in comment 1, though.

Comment 4 Jay Boyd 2017-10-17 18:27:06 UTC
Still an open issue in upstream - 
https://github.com/kubernetes-incubator/service-catalog/issues/722

Comment 5 Jeff Peeler 2017-10-20 14:51:35 UTC
The latest merged PR: https://github.com/openshift/origin/pull/16908 adds --version information (bug 1476134). The next service catalog rebase will contain proper values to be reported from the /version endpoint.

Comment 6 Jeff Peeler 2017-10-25 18:17:00 UTC
Rebase PR (merged): https://github.com/openshift/origin/pull/17027

Comment 8 Xingxing Xia 2017-10-26 07:31:33 UTC
Per https://url.corp.redhat.com/3a0e336 (RH internal) "For origin PR" part, know the fix is merged in ver >= v3.7.0-0.179.0
Will verify on OCP when env >= v3.7.0-0.179.0 is available

Comment 9 Xingxing Xia 2017-10-26 07:38:03 UTC
But verification fails when pre testing on Origin (oc cluster up env):
$ oc get pod --all-namespaces
kube-service-catalog                apiserver-231842995-2jpwq             2/2       Running     0          4h
kube-service-catalog                controller-manager-3856076258-2d76p   1/1       Running     2          4h
openshift-template-service-broker   apiserver-vvbgn                       1/1       Running     0          4h

$ oc rsh -n kube-service-catalog controller-manager-3856076258-2d76p service-catalog controller-manager --version
v0.1.0

$ oc rsh -n kube-service-catalog apiserver-231842995-2jpwq service-catalog controller-manager --version
Defaulting container name to apiserver.
v0.1.0

$ oc version
oc v3.7.0-alpha.1+598a4ac-1328
kubernetes v1.7.6+a08f5eeb62
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://localhost:8443
openshift v3.7.0-alpha.1+598a4ac-1328
kubernetes v1.7.6+a08f5eeb62

^ **** The output does not include service catalog version

But per below check, the PR #17027 is already included in the tested oc/env version "598a4ac"
$ cd github.com/openshift/origin && git pull
$ git log --pretty="%h %cd - %s (%an)" --date=local 598a4ac | grep "#17027"
951a379 Thu Oct 26 01:44:57 2017 - Merge pull request #17027 from jpeeler/sc-rebase-0.1.0 (OpenShift Merge Robot)

Comment 10 Jeff Peeler 2017-10-26 19:20:33 UTC
This bug from the development standpoint wasn't intending on implementing "oc version" to output service catalog information. Apologies for not making this clear sooner. I've confirmed with both Fabiano and Paul that it is ok (and preferred) not to do so.

As described in comment #5, the --version argument works on the binaries as well as querying the endpoint information from the version endpoint. Note that the version endpoint information is tied to origin, so I recommend using the --version argument for a more direct indication of what upstream code was used.

Comment 11 Xingxing Xia 2017-10-27 07:00:35 UTC
(In reply to Jeff Peeler from comment #10)
> This bug ... wasn't intending on implementing
> "oc version" to output service catalog information...confirmed with both Fabiano and Paul that it is ok
> (and preferred) not to do so.
Then comment 3 already verified the bug. Checked in recent v3.7.0-0.178.0 env with service catalog apiserver/controller-manager Running, `oc version` works well in getting openshift version

Comment 14 errata-xmlrpc 2017-11-28 22:04:10 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/RHSA-2017:3188


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