Bug 1217400 - podman netavark macvlan times out on s390x
Summary: podman netavark macvlan times out on s390x
Status: RESOLVED INVALID
Alias: None
Product: PUBLIC SUSE Linux Enterprise Server 15 SP6
Classification: openSUSE
Component: Containers (show other bugs)
Version: unspecified
Hardware: Other Other
: P1 - Urgent : Normal
Target Milestone: ---
Assignee: Containers Team
QA Contact:
URL: https://openqa.suse.de/tests/12864575...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-11-22 12:48 UTC by Felix Niederwanger
Modified: 2023-12-07 15:37 UTC (History)
5 users (show)

See Also:
Found By: openQA
Services Priority:
Business Priority:
Blocker: Yes
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Niederwanger 2023-11-22 12:48:43 UTC
openQA detects a timeout on 15-SP6 (Snapshot 1, Build 39.1) in the podman macvlan driver when waiting for a dhcp lease: https://openqa.suse.de/tests/12864575/modules/podman_netavark/steps/230:

> # podman network create -d macvlan --interface-name eth0 test_macvlan
> # podman run --network test_macvlan -td --name busybox_ctr registry.opensuse.org/opensuse/bci/bci-busybox
> Error: netavark: unable to obtain lease: dhcp proxy error: status: Aborted, message: "Could not find a lease within the timeout limit", details: [], metadata: MetadataMap { headers: {"content-type": "application/grpc", "date": "Wed, 22 Nov 2023 10:40:30 GMT", "content-length": "0"} }

This issue is limited to s390x and not present on x86_64 or aarch64.
Comment 1 Dan Čermák 2023-11-23 10:02:35 UTC
I can reproduce this issue, however I am not sure whether this is actually a regression. The respective test is only enabled for netavark >= 1.6.0 which we never shipped in SLE before. All previous runs were red too and afaik we do not test Tumbleweed in openQA on s390x due to infra issues. Hence this could be an issue that has been always there on s390x.

The underlying issue appears to be that podman does not receive an answer to the dhcpdiscover packet.
Comment 2 Marcela Maslanova 2023-11-27 12:47:27 UTC
I don't know from those reports if you are running it on top of KVM. Did you setup the dhcp server? The failure looks like missing dhcp running.
Comment 3 Dan Čermák 2023-12-07 11:13:01 UTC
I have tested this on bare metal *with* a dhcp server running in the same network and the bug is not reproducible. I suspect that this is a bug in openQA or the test setup.
Comment 4 Felix Niederwanger 2023-12-07 14:47:56 UTC
(In reply to Dan Čermák from comment #3)
> I have tested this on bare metal *with* a dhcp server running in the same
> network and the bug is not reproducible. I suspect that this is a bug in
> openQA or the test setup.

Thank you Dan. I created https://progress.opensuse.org/issues/152194 for investigating this issue from our side.

Can you provide a bit more information about the used setup? How did you established the DHCP server? Locally on the machine or within the network?
Comment 5 Dan Čermák 2023-12-07 15:27:01 UTC
> Can you provide a bit more information about the used setup? How did you
> established the DHCP server? Locally on the machine or within the network?

I've used a VM created on the LinuxONE in Prague and moved it into a VLAN that has a DHCP server running. I have not setup the DHCP server myself, it was already setup there by the SUMA team.