Bug 1679510

Summary: The apiserver pods of Service Catalog crashed
Product: OpenShift Container Platform Reporter: Jian Zhang <jiazha>
Component: Service CatalogAssignee: Jay Boyd <jaboyd>
Status: CLOSED DUPLICATE QA Contact: Jian Zhang <jiazha>
Severity: high Docs Contact:
Priority: high    
Version: 4.1.0   
Target Milestone: ---   
Target Release: 4.1.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-02-26 13:47:54 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:

Description Jian Zhang 2019-02-21 09:58:59 UTC
Description of problem:
The pods of apiserver of Service Catalog crashed.
mac:cluster-svcat-controller-manager-operator jianzhang$ oc get pods
NAME              READY     STATUS             RESTARTS   AGE
apiserver-cxgl9   0/1       CrashLoopBackOff   4          4m29s
apiserver-m96zt   0/1       CrashLoopBackOff   4          4m29s
apiserver-wxzzf   0/1       CrashLoopBackOff   4          4m29s


Version-Release number of selected component (if applicable):
image: registry.svc.ci.openshift.org/openshift/origin-v4.0:service-catalog
commit id: b24ffd6f826fe094a49afc04a5d62ab65490bb37

How reproducible:
always


Steps to Reproduce:
1. Create the OCP 4.0 via the openshift-installer.
2. Install the 
1) git clone https://github.com/openshift/cluster-svcat-apiserver-operator.git
2) oc create -f cluster-svcat-apiserver-operator/manifest
3) oc create -f cluster-svcat-apiserver-operator/hack/cluster-svcat-apiserver-cr.yaml

3. Check the pods.

Actual results:
The pods crashed as the above show, logs as below:
mac:cluster-svcat-controller-manager-operator jianzhang$ oc logs apiserver-wxzzf
W0221 08:00:26.518292       1 feature_gate.go:198] Setting GA feature gate OriginatingIdentity=true. It will be removed in a future release.
I0221 08:00:26.518558       1 hyperkube.go:192] Service Catalog version v4.0.0-v0.1.38+b24ffd6-8-dirty;Upstream:v0.1.38 (built 2019-02-19T05:53:08Z)
W0221 08:00:27.204525       1 util.go:112] OpenAPI spec will not be served
I0221 08:00:27.205863       1 util.go:182] Admission control plugin names: [NamespaceLifecycle MutatingAdmissionWebhook ValidatingAdmissionWebhook DefaultServicePlan ServiceBindingsLifecycle ServicePlanChangeValidator BrokerAuthSarCheck]
I0221 08:00:27.206634       1 plugins.go:158] Loaded 6 mutating admission controller(s) successfully in the following order: NamespaceLifecycle,MutatingAdmissionWebhook,DefaultServicePlan,ServiceBindingsLifecycle,ServicePlanChangeValidator,BrokerAuthSarCheck.
I0221 08:00:27.206654       1 plugins.go:161] Loaded 1 validating admission controller(s) successfully in the following order: ValidatingAdmissionWebhook.
F0221 08:00:47.209829       1 storage_decorator.go:57] Unable to create storage backend: config (&{ /registry [https://etcd.kube-system.svc.cluster.local:2379] /var/run/secrets/etcd-client/tls.key /var/run/secrets/etcd-client/tls.crt /var/run/configmaps/etcd-serving-ca/ca-bundle.crt true true 0 {0xc420109c20 0xc420109cb0} <nil> 5m0s 1m0s}), err (context deadline exceeded) 


Expected results:
The pods running well.

Additional info:

Comment 1 Jay Boyd 2019-02-26 13:47:54 UTC
Is this a multi tenant deployment?  

https://bugzilla.redhat.com/show_bug.cgi?id=1679511

*** This bug has been marked as a duplicate of bug 1679511 ***

Comment 2 Jian Zhang 2019-02-27 02:33:34 UTC
Jay,

> Is this a multi tenant deployment? 

yes, I think so. I'm sorry, I should have updated the information on this bug. I must have missed it.