Draft: Check and fix for podman network_backend consistency when embedding containers (HMS-8783)#1365
Draft: Check and fix for podman network_backend consistency when embedding containers (HMS-8783)#1365thozza wants to merge 7 commits intoosbuild:mainfrom
network_backend consistency when embedding containers (HMS-8783)#1365Conversation
thozza
force-pushed
the
el9-podman-network_backend-fix
branch
from
0cf9369 to
551bc50
Compare
achilleas-k
left a comment
achilleas-k
left a comment
There was a problem hiding this comment.
Really nice! Thank.
The last commit message is a bit too long. Can you make it shorter?
Will do. I hoped that GH will mark this PR as a Draft. 😇 My plan is first to see where the consistency check fails, before pushing any fix for RHEL-9. |
thozza
force-pushed
the
el9-podman-network_backend-fix
branch
2 times, most recently
from
d27bc35 to
4b9ecd5
Compare
thozza
force-pushed
the
el9-podman-network_backend-fix
branch
2 times, most recently
from
d647bc5 to
341bda0
Compare
|
This PR is stale because it has been open 30 days with no activity. Remove "Stale" label or comment or this will be closed in 7 days. |
|
Do we still want this? EDIT: Nvm, noticed you un-staled it. |
|
This PR is stale because it had no activity for the past 30 days. Remove the "Stale" label or add a comment, otherwise this PR will be closed in 7 days. |
thozza
changed the title
network_backend consistency when embedding containersnetwork_backend consistency when embedding containers (HMS-8783)
|
This PR is stale because it had no activity for the past 30 days. Remove the "Stale" label or add a comment, otherwise this PR will be closed in 7 days. |
|
boop |
|
This PR is stale because it had no activity for the past 30 days. Remove the "Stale" label or add a comment, otherwise this PR will be closed in 7 days. |
|
This PR is stale because it had no activity for the past 30 days. Remove the "Stale" label or add a comment, otherwise this PR will be closed in 7 days. |
|
This PR is stale because it had no activity for the past 30 days. Remove the "Stale" label or add a comment, otherwise this PR will be closed in 7 days. |
|
This PR is stale because it had no activity for the past 30 days. Remove the "Stale" label or add a comment, otherwise this PR will be closed in 7 days. |
|
This PR is stale because it had no activity for the past 30 days. Remove the "Stale" label or add a comment, otherwise this PR will be closed in 7 days. |
|
This PR is stale because it had no activity for the past 30 days. Remove the "Stale" label or add a comment, otherwise this PR will be closed in 7 days. |
Verify that containers listed in the blueprint are actually present in the booted image's podman storage. Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Verify that rootful and rootless podman report the same network backend. When containers are embedded as root into the image (the default behavior), some podman versions interpret the existing storage as a migration and fall back to 'cni' for rootful only, leaving rootless on 'netavark'. In practice, the desired behavior is that podman uses the same network backend, regardless if there is an embedded container or not. Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Certain versions of Podman (notably on RHEL 9) fall back to the legacy 'cni' network backend when they find existing container images in the system storage, assuming a migration from an older version. This is problematic for disk images that embed containers as a customization, because the legacy backend packages are not installed by default. Add a NetworkBackend type and a helper to generate the /var/lib/containers/storage/defaultNetworkBackend file, which tells Podman which backend to use and prevents the unwanted fallback. Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Add a new ImageConfig option that specifies the default network backend for Podman. When set and the image embeds container images, the value is written to /var/lib/containers/storage/defaultNetworkBackend during image build. This prevents Podman from falling back to the legacy 'cni' backend when it finds pre-existing container images in storage, which it interprets as a system migration. Signed-off-by: Tomáš Hozza <thozza@redhat.com>
RHEL 9 Podman falls back to the legacy 'cni' network backend when it finds pre-existing container images in storage, but the 'cni' packages are not installed by default. Force 'netavark' so that images with embedded containers work out of the box. This only affects RHEL 9 / CentOS Stream 9; newer distros (and newer podman versions) don't have this fallback logic. Regenerate test manifests. All el9 / c9s manifests that embed containers now get the podman default network backend set. Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Verify the podman default network backend behavior at multiple levels: - YAML loading: fake distro YAML with podman_default_net_backend loads correctly into ImageConfig - osCustomizations: the backend file is generated only when both containers are present and the option is set - Real distro cross-check: RHEL 9 has it set to netavark, while Fedora and RHEL 10 leave it unset Also move the backend file generation in osCustomizations() to after the file customizations assignment, which would otherwise overwrite it. Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Add podman to the package list and a container reference to the all-customizations test blueprint so that the container embedding and network backend consistency host checks have something to verify. Regenerate manifest checksums to reflect the updated test config and the new defaultNetworkBackend file in RHEL 9 / CentOS Stream 9 manifests. Signed-off-by: Tomáš Hozza <thozza@redhat.com>
thozza
force-pushed
the
el9-podman-network_backend-fix
branch
from
341bda0 to
219ac1e
Compare
|
I just pushed a reworked WIP I had locally, since I won't have time to finish it in the upcoming weeks. That said, I didn't want to keep it just locally... |
2 participants
WIP