Bug 1471717
Summary: | oc version cannot get openshift version against ansible deployed service catalog env | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Xingxing Xia <xxia> |
Component: | Service Broker | Assignee: | Jeff Peeler <jpeeler> |
Status: | CLOSED ERRATA | QA Contact: | Xingxing Xia <xxia> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3.6.0 | CC: | akostadi, aos-bugs, chezhang, jokerman, lxia, mmccomas, pmorie, wmeng, wsun |
Target Milestone: | --- | ||
Target Release: | 3.7.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | No Doc Update | |
Doc Text: |
undefined
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2017-11-28 22:04:10 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Comment 1
Derek Carr
2017-07-17 14:55:30 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. > 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 |