Bug 1273818
| Summary: | [intservice_public_121] Met "x509: cannot validate certificate for 10.109.187.185 because it doesn't contain any IP SANs" in heapster Pod | |||
|---|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | chunchen <chunchen> | |
| Component: | Hawkular | Assignee: | Jordan Liggitt <jliggitt> | |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | chunchen <chunchen> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | unspecified | CC: | aos-bugs, jcantril, mwringe, spadgett, wsun, yanpzhan | |
| Target Milestone: | --- | |||
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1277842 (view as bug list) | Environment: | ||
| Last Closed: | 2015-11-23 21:16:45 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: | ||||
|
Description
chunchen
2015-10-21 10:18:40 UTC
I was finally able to reproduce the problem locally on my machine and I understand why it was working locally for me and would cause problems for almost anyone else. Its currently being tracked upstream at https://github.com/kubernetes/heapster/issues/663 There should be a simple work around for this (at least for now) but the work around doesn't work in this situation: https://github.com/kubernetes/heapster/issues/662 There are a couple of more elaborate work arounds: 1) set the hostname of the node to its ip address. This is why it was working for me locally without problem. 2) reconfigure your system to use the RO endpoint. This will get around the issue, but it requires extra steps when configuring your OpenShift instance and is not a setup we should be using. This appears to be an issue with how OpenShift generates its certificates: https://github.com/openshift/origin/issues/5294 The easy work around for now is to set the --hostname to the IP address of the host instead of the actual hostname when generating your configuration. *** Bug 1272976 has been marked as a duplicate of this bug. *** (In reply to Matt Wringe from comment #2) > This appears to be an issue with how OpenShift generates its certificates: > https://github.com/openshift/origin/issues/5294 > > The easy work around for now is to set the --hostname to the IP address of > the host instead of the actual hostname when generating your configuration. Yeah, It works for me when setting the --hostname to the IP address of the host. Duplicate Github issue: https://github.com/openshift/origin/issues/5294 Reassigning to liggitt as he owned the github issue It's fixed, checked on devenv_rhel7_2619, please refer to the below messages: [root@ip-172-18-3-105 hack]# ps -ef |grep open root 18023 17995 8 21:16 pts/0 00:01:27 openshift start --public-master=ec2-52-91-81-137.compute-1.amazonaws.com --latest-images=true root 22387 17995 0 21:33 pts/0 00:00:00 grep --color=auto open [chunchen@F17-CCY daily]$ oc logs heapster-s4d21 <---------------snip------------------> I1102 02:37:40.029869 1 kubelet.go:99] url: "https://172.18.3.105:10250/stats/default/docker-registry-1-f5yg7/f640ce06-8107-11e5-92d2-0ecb98477595/registry", body: "{\"num_stats\":60,\"start\":\"2015-11-02T02:37:35Z\",\"end\":\"2015-11-02T02:37:40Z\"}", data: {ContainerReference:{Name:/system.slice/docker-94352b158cbdce23a6c5b996028a9f33b55284b9cff6d5c062b51b3fa36e213a.scope Aliases:[k8s_registry.99d9127d_docker-registry-1-f5yg7_default_f640ce06-8107-11e5-92d2-0ecb98477595_e5a37810 94352b158cbdce23a6c5b996028a9f33b55284b9cff6d5c062b51b3fa36e213a] Namespace:docker} Subcontainers:[] Spec:{CreationTime:2015-11-02 02:19:02.804101333 +0000 UTC Labels:map[License:GPLv2 Vendor:CentOS io.kubernetes.pod.name:default/docker-registry-1-f5yg7 io.kubernetes.pod.terminationGracePeriod:30] HasCpu:true Cpu:{Limit:2 MaxLimit:0 Mask:0-1} HasMemory:true Memory:{Limit:18446744073709551615 Reservation:0 SwapLimit:18446744073709551615} HasNetwork:false HasFilesystem:false HasDiskIo:true HasCustomMetrics:false CustomMetrics:[]} Stats:[0xc20867fa00 0xc20867fc00 0xc2082be000]} I am a bit confused over why 1277842 was created and why it blocks this issue. Is 1277842 not a duplicate of this issue? Or does it need to exist because of the specific version number? Sorry for confusing, this issue is fixed on Origin, but the bug 1277842 is reproduced against OSE env, I am deleting the blocks. |