Packaging a CNI conflist conflicts with Kubernetes-focused CNIs

[fasaxc]

CRI-O now bundles a bridge CNI conflist at install time (presumably to make CRI-O work out-of-the-box for local pods). This causes an issue in Kubernetes because Kubernetes generally requires a multi-node CNI (such as Calico), which is typically installed as a group of Kubernetes pods.

If there is no CNI installed, Kubernetes will block scheduling of CNI-networked pods, allowing for the CNI itself to bootstrap first and then provision the CNI config. However, with the bridge CNI pre-installed, some pods can get scheduled before the intended CNI has bootstrapped, resulting in some pods being provisioned on the local bridge network, instead of, say, Calico.

There may be more moving parts; I'm not 100% sure which pods can and cannot be scheduled before the intended CNI comes up (Kubernetes also has a "NetowrkUnavilable" taint that the CNI or cloud provider is supposed to remove). However, a user of Calico reported that some of Calico's pods were getting scheduled on the CRIO bridge network where normally they would wait for Calico to bootstrap.

Old issue with similar problem: cri-o/cri-o#5799 (comment) I think it was resolved by removing the bridge config, but that seems to have been regressed.

[saschagrunert]

I'm not sure if we should remove the config. Maybe putting it into a recommended extra package. But that seems to be a lot for a single config file.

@cri-o/cri-o-maintainers what are your thoughts on that?

[haircommander]

yeah I think separating the packages is probably the best option

[kwilczynski]

I think a dedicated package might be an overkill. I would put the files into /usr/share/crio or perhaps change their name to have the .disabled or .example suffix and keep them where they currently are, only to prevent them from being loaded automatically.

Whichever approach, the user-facing documentation has to be updated to let users know about the default configuration.

[saschagrunert]

Sounds like a good idea, proposing that in #202