Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 2034886

Summary:	IBM Public Cloud SDN: csi-driver-registrar container can not start, No CNI configuration file in /etc/kubernetes/cni/net.d/
Product:	OpenShift Container Platform	Reporter:	Qiujie Li <qili>
Component:	Storage	Assignee:	aos-storage-staff <aos-storage-staff>
Storage sub component:	Storage	QA Contact:	Qiujie Li <qili>
Status:	CLOSED DUPLICATE	Docs Contact:
Severity:	high
Priority:	unspecified	CC:	aos-bugs, chaoyang, ffernand, jsafrane, pamoedom
Version:	4.10
Target Milestone:	---
Target Release:	---
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:	2022-01-06 16:38:02 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:

Comment 2 ffernand 2021-12-22 15:22:35 UTC

Warning  NetworkNotReady  3h23m (x11 over 3h23m)   kubelet            network is not ready: container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: No CNI configuration file in /etc/kubernetes/cni/net.d/. Has your network provider started?
Normal   AddedInterface   3h23m                    multus             Add eth0 [10.131.0.20/23] from openshift-sdn

We think container runtime network not ready is a red-herring. 
You can see multus is in ready state and it assigns interface immediately.
Looking at the output of oc-get-co we can see that the network is in a healthy state. This does not seem like a netw issue.
Please re-assign if that is not the case.

IBMVPCBlockCSIDriverOperatorCRProgressing seem to be the component having issues.

Re-assigning to storage, but not sure what is the right sub-component.

Comment 4 Chao Yang 2022-01-05 11:16:32 UTC

Also meet similar issue https://bugzilla.redhat.com/show_bug.cgi?id=2037276
oc logs ibm-vpc-block-csi-node-x9xn2 -c vpc-node-label-updater
{"level":"info","timestamp":"2022-01-05T06:25:05.847Z","caller":"cmd/main.go:105","msg":"Starting controller for adding node labels","watcher-name":"vpc-node-label-updater"}
{"level":"info","timestamp":"2022-01-05T06:25:16.259Z","caller":"cmd/main.go:113","msg":"Error retrieving the Node from the index for a given node. Error :","watcher-name":"vpc-node-label-updater","error":"Get \"https://172.30.0.1:443/api/v1/nodes/qe-chaoibm10-cxqj6-worker-1-7zq9m\": dial tcp 172.30.0.1:443: connect: connection refused"}

Comment 5 Qiujie Li 2022-01-06 04:43:23 UTC

Remove TestBlocker for now as chaoyang said there could be a workaround. I'll verify this workaround when I get a successful install.
update label for node:
 vpc-block-csi-driver-labels: “true”
 ibm-cloud.kubernetes.io/worker-id: xx

Comment 6 Jan Safranek 2022-01-06 16:38:02 UTC

I am marking this as dup of 2037276 - CSI driver pods can get to CrashLoop if its init container failed. However, it has nothing to do with "CNI configuration file in /etc/kubernetes/cni/net.d/", I think it's just a coincidence.

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