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

"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.

> 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.

Still an open issue in upstream - 
https://github.com/kubernetes-incubator/service-catalog/issues/722

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.

Rebase PR (merged): https://github.com/openshift/origin/pull/17027

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

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)

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.

(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

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