With rc2 and -plugins installed, I'm getting warning messages like this with old cni config files from previous (i.e. 4.3.1) versions of podman:
podman run -it --net=host -v /home/martjack/gitwork/newprints/docs:/site:"rw,z" --entrypoint htmltest quay.io/hybridcloudpatterns/homepage-container:latest
WARN[0000] Error validating CNI config file /home/martjack/.config/cni/net.d/87-podman.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]]
Is this expected? I removed the conflist files and that makes the warnings go away (and things still work).
Also, it seems that -quadlet has to be installed "intentionally"; I'm assuming this is deliberate for now, as -quadlet is still in "preview" mode, but I wanted to note it here just in case.
This update's test gating status has been changed to 'failed'.
This seems to break overriding of the storage driver in /etc/container/storage.conf.
I have
[storage]
driver = "zfs"
in my /etc/containers/storage.conf. I did not modify /usr/share/containers/storage.conf, which contains the default driver "overlay".
With a clean system, the storage gets set to overlay:
# podman info -f '{{.Store.ConfigFile}}'
/etc/containers/storage.conf
# podman info -f '{{.Store.GraphDriverName}}'
overlay
With a system that has been previously initialized to use ZFS, any podman command fails with
ERRO[0000] User-selected graph driver "overlay" overwritten by graph driver "zfs" from database - delete libpod local files ("/var/lib/containers/storage") to resolve. May prevent use of images created by other tools
# strace -o openat podman info tells me that /etc/containers/storage.conf is read, followed by/usr/share/containers/storage.conf. And indeed, if I change the driver to zfs in /usr/share/containers/storage.conf, it is used as expected. However, /etc/containers/storage.conf should be the file that has the final say on things, not the one in /usr/share.
unpushing. Current fedora setup is a PITA to test RCs so I will skip kojis and bodhis for all further RCs on non-rawhide envs. There will always be bugfix releases. Makes my life easier too.
There's a new incoming CVE-2022-41717 so everything is likely gonna get mass rebuilt. I've bumped the epoch and reverted to the last stable so podman is all set.
> Current fedora setup is a PITA to test RCs so I will skip kojis and bodhis for all further RCs on non-rawhide envs.
Well, it's not supposed to be used for this in the first place. Bodhi is meant for testing updates that are intended to be pushed to stable.
From the Updates Policy:
> Bodhi updates should only be created for builds which are expected to qualify for being pushed to stable. Maintainers should not use Bodhi’s testing states to test updates they never intend to push stable. This sort of testing should be done in Copr or other seperate public repositories. Consult with the QA team for further testing assistance.
sure, but how many people care to enable an additional copr? There's often a month between the first podman rc and it's .0 release. That is a month without a lot of community feedback. One option might be to just not do RCs and do more bugfix releases instead. Anyway, I'll see what the podman team has to say. Thanks.
@gotmax23 was the rebuild of podman for f38 blocked because of this issue? Just trying to understand why an f38 mass rebuild would be blocked on f37. The rawhide build of the podman rc was already moved to stable.
For help debugging failed Fedora CI tests (fedora-ci.*), contact the Fedora CI team.
For help debugging failed Fedora CoreOS tests (coreos.*), contact the Fedora CoreOS team.
For help debugging failed openQA tests (update.*), contact the Fedora Quality team, who will usually investigate and diagnose all failures within 24 hours.
This update has been submitted for testing by lsm5.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
This update has been pushed to testing.
Works well with some basic container tests + docker-compose.
Works for me, including quadlet functions.
lsm5 edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update has been submitted for testing by lsm5.
This update's test gating status has been changed to 'waiting'.
added v4.4.0-rc2. Still gonna stay in testing until final release is out. Thanks!
With rc2 and -plugins installed, I'm getting warning messages like this with old cni config files from previous (i.e. 4.3.1) versions of podman:
podman run -it --net=host -v /home/martjack/gitwork/newprints/docs:/site:"rw,z" --entrypoint htmltest quay.io/hybridcloudpatterns/homepage-container:latest WARN[0000] Error validating CNI config file /home/martjack/.config/cni/net.d/87-podman.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]]Is this expected? I removed the conflist files and that makes the warnings go away (and things still work).
Also, it seems that -quadlet has to be installed "intentionally"; I'm assuming this is deliberate for now, as -quadlet is still in "preview" mode, but I wanted to note it here just in case.
This update's test gating status has been changed to 'failed'.
@mhjacks I'll verify the quadlet dependency with the team and do a new build. Thanks.
Thanks @lsm5!
Also - update on the warnings above - I have found that this installation of podman was still using the cni backend, so these warnings were expected.
wfm
@mhjacks so I'm told quadlet needs podman but not the other way around. So, users will need to intentionally install quadlet like you pointed out.
This update has been pushed to testing.
Please don't do this. Automatic rebuilds will pick up this commit and push it to stable.
This seems to break overriding of the storage driver in /etc/container/storage.conf.
I have
in my
/etc/containers/storage.conf. I did not modify/usr/share/containers/storage.conf, which contains the default driver "overlay".With a clean system, the storage gets set to overlay:
With a system that has been previously initialized to use ZFS, any podman command fails with
# strace -o openat podman infotells me that/etc/containers/storage.confis read, followed by/usr/share/containers/storage.conf. And indeed, if I change the driver to zfs in/usr/share/containers/storage.conf, it is used as expected. However,/etc/containers/storage.confshould be the file that has the final say on things, not the one in/usr/share.This may or may not be related to https://github.com/containers/storage/pull/1468 (which went into storage v1.45.1, but isn't used in this version of podman). See also https://github.com/containers/storage/issues/1469.
On a positive note, I can confirm https://github.com/containers/storage/commit/07ed7f4b7f544b62d5dd37d07e31edbd59d0a395 works.
unpushing. Current fedora setup is a PITA to test RCs so I will skip kojis and bodhis for all further RCs on non-rawhide envs. There will always be bugfix releases. Makes my life easier too.
This update has been unpushed.
There's a new incoming CVE-2022-41717 so everything is likely gonna get mass rebuilt. I've bumped the epoch and reverted to the last stable so podman is all set.
> Current fedora setup is a PITA to test RCs so I will skip kojis and bodhis for all further RCs on non-rawhide envs.
Well, it's not supposed to be used for this in the first place. Bodhi is meant for testing updates that are intended to be pushed to stable.
From the Updates Policy:
> Bodhi updates should only be created for builds which are expected to qualify for being pushed to stable. Maintainers should not use Bodhi’s testing states to test updates they never intend to push stable. This sort of testing should be done in Copr or other seperate public repositories. Consult with the QA team for further testing assistance.
-- https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#consumable-updates
sure, but how many people care to enable an additional copr? There's often a month between the first podman rc and it's .0 release. That is a month without a lot of community feedback. One option might be to just not do RCs and do more bugfix releases instead. Anyway, I'll see what the podman team has to say. Thanks.
@gotmax23 was the rebuild of podman for f38 blocked because of this issue? Just trying to understand why an f38 mass rebuild would be blocked on f37. The rawhide build of the podman rc was already moved to stable.