Hi guys. I'm seeing something strange and I hoped experts/devel would comment, on: -> $ podman network ls NETWORK ID NAME DRIVER 2f259bab93aa podman bridge -> $ podman system reset --force -> $ podman network ls WARN[0000] Error validating CNI config file /etc/cni/net.d/87-podman-bridge.conflist: [failed to find plugin "bridge" in path [/usr/local/libexec/cni /usr/libexec/cni /usr/local/lib/cni /usr/lib/cni /opt/cni/bin] failed to find plugin "portmap" in path [/usr/local/libexec/cni /usr/libexec/cni /usr/local/lib/cni /usr/lib/cni /opt/cni/bin] failed to find plugin "firewall" in path [/usr/local/libexec/cni /usr/libexec/cni /usr/local/lib/cni /usr/lib/cni /opt/cni/bin] failed to find plugin "tuning" in path [/usr/local/libexec/cni /usr/libexec/cni /usr/local/lib/cni /usr/lib/cni /opt/cni/bin]] NETWORK ID NAME DRIVER 2f259bab93aa podman bridge then I ssh-log out & in, things seem okey: -> $ podman network ls NETWORK ID NAME DRIVER 2f259bab93aa podman bridge and if I 'reset' then in circles it goes. what is actually happening here? Is system setup/installation missing something? many thanks, L.
Hi Lejeczek, It seems that the behavior is similar to this ticket( https://github.com/containers/podman/issues/13396). my assuming is that system resets setting by performing ‘podman system reset’ command and it looks like setup with CNI warns due to not utilizing containernetworking-plugins and netavark setting is internally selected by ‘podman network ls’ command at the first attempt after the reset, which of status is cached. Best Regards, Taro 2023年5月6日(土) 18:31 lejeczek via Podman <podman@lists.podman.io>:
Hi guys.
I'm seeing something strange and I hoped experts/devel would comment, on:
-> $ podman network ls NETWORK ID NAME DRIVER 2f259bab93aa podman bridge
-> $ podman system reset --force
-> $ podman network ls WARN[0000] Error validating CNI config file /etc/cni/net.d/87-podman-bridge.conflist: [failed to find plugin "bridge" in path [/usr/local/libexec/cni /usr/libexec/cni /usr/local/lib/cni /usr/lib/cni /opt/cni/bin] failed to find plugin "portmap" in path [/usr/local/libexec/cni /usr/libexec/cni /usr/local/lib/cni /usr/lib/cni /opt/cni/bin] failed to find plugin "firewall" in path [/usr/local/libexec/cni /usr/libexec/cni /usr/local/lib/cni /usr/lib/cni /opt/cni/bin] failed to find plugin "tuning" in path [/usr/local/libexec/cni /usr/libexec/cni /usr/local/lib/cni /usr/lib/cni /opt/cni/bin]] NETWORK ID NAME DRIVER 2f259bab93aa podman bridge
then I ssh-log out & in, things seem okey: -> $ podman network ls NETWORK ID NAME DRIVER 2f259bab93aa podman bridge
and if I 'reset' then in circles it goes.
what is actually happening here? Is system setup/installation missing something?
many thanks, L. _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
On 07/05/2023 08:34, Taro Yokoyama wrote:
Hi Lejeczek, It seems that the behavior is similar to this ticket(https://github.com/containers/podman/issues/13396).
my assuming is that system resets setting by performing ‘podman system reset’ command and it looks like setup with CNI warns due to not utilizing containernetworking-plugins and netavark setting is internally selected by ‘podman network ls’ command at the first attempt after the reset, which of status is cached.
Best Regards, Taro
2023年5月6日(土) 18:31 lejeczek via Podman <podman@lists.podman.io>:
Hi guys.
I'm seeing something strange and I hoped experts/devel would comment, on:
-> $ podman network ls NETWORK ID NAME DRIVER 2f259bab93aa podman bridge
-> $ podman system reset --force
-> $ podman network ls WARN[0000] Error validating CNI config file /etc/cni/net.d/87-podman-bridge.conflist: [failed to find plugin "bridge" in path [/usr/local/libexec/cni /usr/libexec/cni /usr/local/lib/cni /usr/lib/cni /opt/cni/bin] failed to find plugin "portmap" in path [/usr/local/libexec/cni /usr/libexec/cni /usr/local/lib/cni /usr/lib/cni /opt/cni/bin] failed to find plugin "firewall" in path [/usr/local/libexec/cni /usr/libexec/cni /usr/local/lib/cni /usr/lib/cni /opt/cni/bin] failed to find plugin "tuning" in path [/usr/local/libexec/cni /usr/libexec/cni /usr/local/lib/cni /usr/lib/cni /opt/cni/bin]] NETWORK ID NAME DRIVER 2f259bab93aa podman bridge
then I ssh-log out & in, things seem okey: -> $ podman network ls NETWORK ID NAME DRIVER 2f259bab93aa podman bridge
and if I 'reset' then in circles it goes.
what is actually happening here? Is system setup/installation missing something?
many thanks, L.
It seems that this: /etc/cni/net.d/87-podman.conflist is some remainer of some previous installation, previous version? On a few different systems where the same version of podman is installed that file does not exist and 'system reset' does not seem to care about the file. Also '/etc/udev/rules.d/etc/cni/net.d/87-podman.conflist' existed - past tense as I removed both and now 'system reset' and subsequent operations do not complain about that, no log out&in necessary. thanks, L.
On 5/9/23 14:30, lejeczek via Podman wrote:
It seems that this: /etc/cni/net.d/87-podman.conflist is some remainer of some previous installation
Ahh, that explains perfectly what you're seeing. You're right, it must be a leftover from a previous setup, using an older version of podman. The existence of any config. file in /etc/cni/net.d tells podman to use the "old" CNI networking system. When the directory is empty, you get the "new" netavark system. The two are _NOT_ compatible, forward or backward with each other. When upgrading (and system reset-ing) podman doesn't touch these files - It does the "safe" thing, and assumes there could be some valuable settings inside. It's up to you (when upgrading / switching systems) to migrate the configuration manually (if applicable). Unfortunately, this is not made very clear by the error messages and behaviors. However, what you've found is working as intended - moving/removing those files THEN resetting will put you on the new netavark system - where you'll no longer see the errors. Hope that helps. --- Chris Evich (he/him), RHCA III Senior Quality Assurance Engineer If it ain't broke, your hammer isn't wide 'nough.
To clarify as I am the guy who wrote that code:
The existence of any config. file in /etc/cni/net.d tells podman to use the "old" CNI networking system.
This is not correct. If you only have the default "podman" cni config file it will be ignored by the backend detection and choose netavark. The reason you see the warning is because the code first tries to init the cni backend to check how many networks are configured. This init will also validate the files and thus throw the warning. When we know that you only have the default config we configure netavark and then store this decision in the `defaultNetworkBackend` file in graphroot. SO that is why the warning will only be displayed for the first command. As mentioned the correct way to fix this is to either remove the config file or configure the network backend in containers.conf to not go through the auto detection logic. You could also install containernetworking-plugins to make the warning go away but this isn't needed because you use netavark. Basically the whole idea behind this logic was to support upgrades from 3.X to 4.0 without forcing netavark on them while new installs should default to netavark. --- Paul On Tue, May 9, 2023 at 10:31 PM Chris Evich <cevich@redhat.com> wrote:
On 5/9/23 14:30, lejeczek via Podman wrote:
It seems that this: /etc/cni/net.d/87-podman.conflist is some remainer of some previous installation
Ahh, that explains perfectly what you're seeing. You're right, it must be a leftover from a previous setup, using an older version of podman. The existence of any config. file in /etc/cni/net.d tells podman to use the "old" CNI networking system. When the directory is empty, you get the "new" netavark system. The two are _NOT_ compatible, forward or backward with each other.
When upgrading (and system reset-ing) podman doesn't touch these files - It does the "safe" thing, and assumes there could be some valuable settings inside. It's up to you (when upgrading / switching systems) to migrate the configuration manually (if applicable).
Unfortunately, this is not made very clear by the error messages and behaviors. However, what you've found is working as intended - moving/removing those files THEN resetting will put you on the new netavark system - where you'll no longer see the errors.
Hope that helps.
--- Chris Evich (he/him), RHCA III Senior Quality Assurance Engineer If it ain't broke, your hammer isn't wide 'nough. _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
participants (4)
-
Chris Evich -
lejeczek -
Paul Holzinger -
Taro Yokoyama