Bug 1868403

Summary: CNV 2.4.1 deployment on IPI fails due to kubemacpool errors
Product: Container Native Virtualization (CNV) Reporter: Yossi Segev <ysegev>
Component: InstallationAssignee: Simone Tiraboschi <stirabos>
Status: CLOSED DUPLICATE QA Contact: Inbar Rose <irose>
Severity: unspecified Docs Contact:
Priority: urgent    
Version: 2.4.1CC: cnv-qe-bugs, fdeutsch, stirabos
Target Milestone: ---   
Target Release: 2.4.1   
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: 2020-08-13 14:53:19 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 Yossi Segev 2020-08-12 14:30:27 UTC
Description of problem:
Deploying OCP 4.5/CNV 2.4.1 using fails. Investigating the failure revealed that the kubemacpool pods don't come up.
Devs says its the same issue as in https://bugzilla.redhat.com/show_bug.cgi?id=1857301, which already has a pending PR (https://github.com/kubevirt/hyperconverged-cluster-operator/pull/741).

Version-Release number of selected component (if applicable):
OCP 4.5/CNV 2.4.1


How reproducible:
Not known (only tried once).

Steps to Reproduce:
1. Deploy OCP 4.5/CNV 2.4.1 using https://cnv-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/deploy-ocp-4.5-cnv-2.4-on-rhos-ipi
To reproduce exactly the same parameters used when his bug occured - use the parameters of https://cnv-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/deploy-ocp-4.5-cnv-2.4-on-rhos-ipi/1540/


Actual results:
Deployment fails on CNV stage (OCP deployed successfully).


Additional info:
Kubemacpool-mac-controller-manager pods logs show this:

{"level":"error","ts":1597227559.634002,"logger":"manager","msg":"unable to run the manager","error":"failed watting for ready TLS key/cert: timed out waiting for the condition","errorVerbose":"timed out waiting for the condition\nfailed watting for ready TLS key/cert\ngithub.com/qinqon/kube-admission-webhook/pkg/webhook/server.(*Server).Start\n\t/go/src/github.com/k8snetworkplumbingwg/kubemacpool/vendor/github.com/qinqon/kube-admission-webhook/pkg/webhook/server/server.go:159\nsigs.k8s.io/controller-runtime/pkg/manager.(*controllerManager).startNonLeaderElectionRunnables.func1\n\t/go/src/github.com/k8snetworkplumbingwg/kubemacpool/vendor/sigs.k8s.io/controller-runtime/pkg/manager/internal.go:492\nruntime.goexit\n\t/usr/lib/golang/src/runtime/asm_amd64.s:1357","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/src/github.com/k8snetworkplumbingwg/kubemacpool/vendor/github.com/go-logr/zapr/zapr.go:128\ngithub.com/k8snetworkplumbingwg/kubemacpool/pkg/manager.(*KubeMacPoolManager).Run\n\t/go/src/github.com/k8snetworkplumbingwg/kubemacpool/pkg/manager/manager.go:125\nmain.main\n\t/go/src/github.com/k8snetworkplumbingwg/kubemacpool/cmd/manager/main.go:88\nruntime.main\n\t/usr/lib/golang/src/runtime/proc.go:203"}

Comment 1 Simone Tiraboschi 2020-08-13 14:53:19 UTC

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