Closed Luap99 closed 4 months ago
The test failure doesn't seem related, looks like it relies on a stable TXT entry for wikipedia.org which isn't the case.
It should use a domain under our control that is unlikely to change (podman.io or crc.dev maybe?) or the test must setup a local dns server which returns a stable known TXT record.
@cfergeau PTAL
The test failure doesn't seem related, looks like it relies on a stable TXT entry for wikipedia.org which isn't the case.
It should use a domain under our control that is unlikely to change (podman.io or crc.dev maybe?) or the test must setup a local dns server which returns a stable known TXT record.
Yeah, I hit the test failure while looking at the PR, and came to the same conclusion, especially as there was already a change last month ( https://github.com/containers/gvisor-tap-vsock/commit/79001dbc4480556c61ce2ec64fb0b2acbbb16022 ). I'll add a record to crc.dev
/lgtm /approve
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: cfergeau, Luap99
The full list of commands accepted by this bot can be found here.
The pull request process is described here
/hold till CI gets a chance to run
/unhold
Thanks
@cfergeau Can you create a new release sometime this week? We release podman 5.2 next week and it would be good to get a new gvproxy version into the installer to fix this for podman users.
Thanks
@cfergeau Can you create a new release sometime this week? We release podman 5.2 next week and it would be good to get a new gvproxy version into the installer to fix this for podman users.
Yup, for sure, I'll try to do this today or tomorrow.
@Luap99 I've made the release and created https://github.com/containers/podman/pull/23387
When a high throughput is happeing we send a lot of data into the VM socket, the VM has to read it in order to empty the buffer. This is inherently race so it is possible to get ENOBUFS here. In this case just keep trying writing until it works.
Fixes #367