unpushed

podman-4.4.0~rc2-2.fc37

FEDORA-2023-a0f754c701 created by lsm5 a year ago for Fedora 37

This update will NOT be pushed to stable. But please add karma so we know how it works for you.

This update has been submitted for testing by lsm5.

a year ago

This update's test gating status has been changed to 'waiting'.

a year ago

This update's test gating status has been changed to 'failed'.

a year ago

This update has been pushed to testing.

a year ago
User Icon mhayden commented & provided feedback a year ago
karma

Works well with some basic container tests + docker-compose.

karma
User Icon mhjacks commented & provided feedback a year ago
karma

Works for me, including quadlet functions.

lsm5 edited this update.

New build(s):

  • podman-4.4.0~rc2-2.fc37

Removed build(s):

  • podman-4.4.0~rc1-3.fc37

Karma has been reset.

a year ago

This update has been submitted for testing by lsm5.

a year ago

This update's test gating status has been changed to 'waiting'.

a year ago

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'.

a year ago

@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.

User Icon t3rm1n4l commented & provided feedback a year ago
karma

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.

a year ago

This update will NOT be pushed to stable. But please add karma so we know how it works for you.

Please don't do this. Automatic rebuilds will pick up this commit and push it to stable.

User Icon clang commented & provided feedback a year ago
karma

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.

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.

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.


Please login to add feedback.

Metadata
Type
enhancement
Karma
0
Signed
Content Type
RPM
Test Gating
Settings
Unstable by Karma
-3
Stable by Karma
disabled
Stable by Time
disabled
Dates
submitted
a year ago
in testing
a year ago
modified
a year ago

Automated Test Results