What steps did you take and what happened:
[A clear and concise description of what the bug is.]
Running CABPK controller and CAPI controller in the same namespace. They are contending the leader elect lock
This is log from cabpk controller
yangshan-a02:v1alpha2 yangshan$ kubectl logs cabpk-controller-manager-644f88db48-s5npg -n b721480c4fc12e72896649c35c8543fb03ff1ea4 -f -c manager
I1004 16:29:14.967159 1 reflector.go:370] pkg/mod/k8s.io/client-go@v11.0.1-0.20190409021438-1a26190bd76a+incompatible/tools/cache/reflector.go:94: Watch close - *v1alpha2.Cluster total 0 items received
I1004 16:29:16.789416 1 leaderelection.go:326] lock is held by capi-controller-manager-74cb5b985f-kfmt6_009aa8d2-e577-11e9-be08-629a49ac5bcb and has not yet expired
What did you expect to happen:
They should both aqquire their own leader elect lock
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
I am running a set up with CAPI+CAPA+CABPK in one namespace. CAPI and CAPA seem to live with each other just fine. From the log, there is no error
Environment:
Cluster API version: v0.2.2
Cluster API Bootstrap Provider Kubeadm version: 0.1.1
Cluster API Infrastructure Provider version: v0.4.0
/kind bug
What steps did you take and what happened: [A clear and concise description of what the bug is.] Running CABPK controller and CAPI controller in the same namespace. They are contending the leader elect lock
This is log from cabpk controller
What did you expect to happen: They should both aqquire their own leader elect lock
Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.] I am running a set up with CAPI+CAPA+CABPK in one namespace. CAPI and CAPA seem to live with each other just fine. From the log, there is no error
Environment:
kubectl version
): 1.14/etc/os-release
):