Comment # 7 on bug 1140067 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.