http://bugzilla.suse.com/show_bug.cgi?id=1140067 http://bugzilla.suse.com/show_bug.cgi?id=1140067#c7 Sascha Grunert changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS CC| |sgrunert@suse.com --- Comment #7 from Sascha Grunert --- (In reply to Richard Brown from comment #6)

(In reply to Sascha Grunert from comment #5)

...

(In reply to Marco Vedovati from comment #4)

...

(In reply to Richard Brown from comment #3)

...

If you do that you won’t ever be able to install podman on a machine with a custom chi config, such as one using cri-o/kubernetes

That seems silly, given one of the use cases for podman is troubleshooting containers on systems with cri-o/kubernetes

Sascha WDYT?

I think we could change the libpod.conf to comment out `cni_default_network`. Then podman should select the config with the highest priority in `cni_plugin_dir`. Then we could make podman-cni-config mandatory, because user would still be able to put higher prio configs in.

Good theory, in practice this will not work

Most upstream CNI config files, which of course are generated at container runtime, are not prioritised

So CNI tries to load all of them

So this plan would make Podman toxic to any system

This is why podman implemented the default CNI network parameter, but it has not yet been adopted by CRI-O or any other CNI consumer...

I might miss a point here, but right now we have the 'issue' that libpod.conf does specify: cni_default_network = "podman". This does not exist in a default installation of podman, right? If there is nothing we can do here because of clashing use cases I would recommend to close this issue and we think about a proper upstream solution to provide stronger defaults. -- You are receiving this mail because: You are on the CC list for the bug.