Hide Forgot
Description of problem: Improper configuration of vSphere causing panic Version-Release number of selected component (if applicable): Kube 1.4.4 and below How reproducible: Always Steps to Reproduce: 1.Deploy OCP 3.4 on vSphere 2.Configure Storage Class with vSphere provisioner 3.Create pvc to request Storage class Actual results: Master node fails with panic Expected results: Additional info: Bug is fixed in these: https://github.com/kubernetes/kubernetes/pulls?utf8=%E2%9C%93&q=%20is%3Apr%20author%3Akerneltime%20
https://github.com/openshift/origin/11598
(In reply to Eric Paris from comment #1) > https://github.com/openshift/origin/11598 bad link good link https://github.com/openshift/origin/pull/11598
*** Bug 1391863 has been marked as a duplicate of this bug. ***
another panic: 2016-11-07 19:41:06.047705 I | etcdserver/api/v3rpc: grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp 10.19.114.240:4001: getsockopt: connection refused"; Reconnecting to {10.19.114.240:4001 <nil>} panic: reflect.Set: value of type mo.ResourcePool is not assignable to type mo.ComputeResource https://github.com/kubernetes/kubernetes/issues/36295
Per Mike Barret --- we are moving support for vsphere in 3.4 out thus removing 'blocker'
vSphere is unsupported. We will get improvements in 3.5 from upstream but we are not going to actively work this BZ.