Bug 1652421 - The version of the 4.0 image of the Service Catalog is not correct
Summary: The version of the 4.0 image of the Service Catalog is not correct
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Service Catalog
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ---
: 4.1.0
Assignee: Dan Geoffroy
QA Contact: Jian Zhang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-22 03:23 UTC by Jian Zhang
Modified: 2019-06-04 10:41 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-04 10:41:02 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:0758 None None None 2019-06-04 10:41:08 UTC

Description Jian Zhang 2018-11-22 03:23:55 UTC
Description of problem:
I can pull the image: ose-service-catalog:v4.0 correctly, but I find the version of the service-catalog binary is not correct.

Version-Release number of selected component (if applicable):
OCP 4.0
brewregistry.stage.redhat.io/openshift/ose-service-catalog:v4.0

How reproducible:
always

Steps to Reproduce:
1. Pull the 4.0 image of Service Catalog.
2. Check the version of the service-catalog binary.


Actual results:
[root@qe-jfan-3 ~]# docker run -ti --rm brewregistry.stage.redhat.io/openshift/ose-service-catalog:v4.0 service-catalog --version
v4.0.0-0.66.0;Upstream:v0.1.31

Expected results:
The release version of 3.11 is "Upstream:v0.1.35", so, at least, the version of 4.0 should be newer than it.

Additional info:
[root@qe-jfan-3 ~]# docker run -ti --rm registry.redhat.io/openshift3/ose-service-catalog:v3.11 service-catalog --version
v3.11.43;Upstream:v0.1.35

Comment 1 Jian Zhang 2018-11-26 09:15:57 UTC
Added the TestBlocker since it blocks the functional testing of the 4.0. Correct me if I'm wrong.

Comment 2 Zihan Tang 2018-12-18 09:57:26 UTC
When I install service-catalog with Next-gen installer 4.0 (0.7.0), default service catalog image is :
quay.io/openshift/origin-service-catalog:v4.0.0
but version is old: v3.11.0+5e975ea-2-dirty;Upstream:v0.1.31

After creating ASB or TSB by operator, the controller-manager pod will turn to CrashLoopBackOff.
# oc logs -f controller-manager-7fc4d64bcc-fqtrc
I1218 09:33:18.622794       1 feature_gate.go:194] feature gates: map[OriginatingIdentity:true]
I1218 09:33:18.622903       1 feature_gate.go:194] feature gates: map[OriginatingIdentity:true AsyncBindingOperations:true]
I1218 09:33:18.622926       1 feature_gate.go:194] feature gates: map[OriginatingIdentity:true AsyncBindingOperations:true NamespacedServiceBroker:true]
I1218 09:33:18.622950       1 hyperkube.go:192] Service Catalog version v3.11.0+5e975ea-2-dirty;Upstream:v0.1.31 (built 2018-11-27T03:45:41Z)
I1218 09:33:18.719018       1 leaderelection.go:185] attempting to acquire leader lease  kube-service-catalog/service-catalog-controller-manager...
I1218 09:33:18.924366       1 leaderelection.go:194] successfully acquired lease kube-service-catalog/service-catalog-controller-manager
I1218 09:33:18.924855       1 event.go:221] Event(v1.ObjectReference{Kind:"ConfigMap", Namespace:"kube-service-catalog", Name:"service-catalog-controller-manager", UID:"f5ee8652-0274-11e9-bdd1-0639d6b2fa2a", APIVersion:"v1", ResourceVersion:"263444", FieldPath:""}): type: 'Normal' reason: 'LeaderElection' controller-manager-7fc4d64bcc-fqtrc-external-service-catalog-controller became leader
F1218 09:33:19.421052       1 controller_manager.go:232] error running controllers: failed to get api versions from server: failed to get supported resources from server: unable to retrieve the complete list of server APIs: servicecatalog.k8s.io/v1beta1: the server is currently unable to handle the request

I'm not sure whether it caused by the old version.

Can you help to update service catalog image to the latest in upstream or downstream? Otherwise it blocks the installation testing of service broker.

Comment 3 Zihan Tang 2018-12-19 09:21:27 UTC
For workaround in #comment 2:
remove all resource limit of service-catalog containers in rh-operator config map, then controller-manager pod will be more stable.

Comment 4 Jay Boyd 2018-12-19 18:48:34 UTC
Merged v0.1.38 (latest upstream version) into openshift/service-catalog and verified the updated build is available on quay and dockerhub.

Comment 5 Jian Zhang 2018-12-20 05:47:15 UTC
Jay,

Yes, the version of the Service Catalog is correct. LGTM, verify it.
The image: quay.io/openshift/origin-service-catalog:v4.0.0

mac:20-payload jianzhang$ oc get pods -n kube-service-catalog
NAME                                  READY     STATUS    RESTARTS   AGE
apiserver-6b8d478d77-58vkr            2/2       Running   0          4m
controller-manager-78744c7ccc-w8knh   1/1       Running   7          14h

mac:20-payload jianzhang$ oc exec apiserver-6b8d478d77-58vkr  -- service-catalog --version
Defaulting container name to apiserver.
Use 'oc describe pod/apiserver-6b8d478d77-58vkr -n kube-service-catalog' to see all of the containers in this pod.
v4.0.0-v0.1.38+7a95e74-2-dirty;Upstream:v0.1.38


@Zihan
Please have a try with the latest version. Please create a new bug to trace that issue if it still CrashLoopBackOff.

Comment 6 Jian Zhang 2018-12-20 05:48:03 UTC
Verify it according to comment 5.

Comment 10 errata-xmlrpc 2019-06-04 10:41:02 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/RHBA-2019:0758


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