-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
APIv2: /info is getting slower #8076
Labels
flakes
Flakes from Continuous Integration
HTTP API
Bug is in RESTful API
kind/bug
Categorizes issue or PR as related to a bug.
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
stale-issue
Comments
mheon
added
HTTP API
Bug is in RESTful API
kind/bug
Categorizes issue or PR as related to a bug.
flakes
Flakes from Continuous Integration
labels
Oct 20, 2020
edsantiago
added a commit
to edsantiago/libpod
that referenced
this issue
Oct 20, 2020
- apiv2 - the 'ten /info requests' test is flaking often, taking ~8 seconds (our limit is 7, up from 5 a few weeks ago). Brent suggested that the first /info call might be expensive, because it needs to access storage. So, let's prime it by running one /info outside the timing loop. And, because even that continues to fail, bump it up to 10 seconds and file containers#8076 to track the slowdown. - toolbox test - WaitForReady() has timed out, even on one occasion causing a run failure because it failed 3 times. Solution: bump up timeout from 2s to 5s. Not really great, but CI systems are underpowered, and it's not unreasonable that 2s might be too low. - sdnotify test - add a 'podman wait' between stop & rm. This may prevent a "cannot rm container as it is running" race condition. While working on this, Brent and I noticed a few ways that test-apiv2 logging can be improved: - test name: when request is POST, display the jsonified parameters, not the original input ones. This should make it much easier to reproduce failures. - use curl's "--write-out" option to capture http code, content type, and request time. We were getting the first two via grep from logged headers; this is cleaner. And there was no other way to get timing. We now include the timing as X-Response-Time in the log file. - abort on *any* curl error, not just 7 (cannot connect). Any error at all from curl is bad news. Signed-off-by: Ed Santiago <[email protected]>
A friendly reminder that this issue had no activity for 30 days. |
maybe could close this ? |
@edsantiago PTAL |
A friendly reminder that this issue had no activity for 30 days. |
Closing do to lack of activity. |
github-actions
bot
added
the
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
label
Sep 22, 2023
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
flakes
Flakes from Continuous Integration
HTTP API
Bug is in RESTful API
kind/bug
Categorizes issue or PR as related to a bug.
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
stale-issue
The "ten /info requests" timing test is getting slower:
podman/test/apiv2/01-basic.at
Lines 62 to 78 in 3668211
It was bumped up from 5 to 7 seconds last week, and is about to get bumped up to 10 (#8065) because it is causing CI flakes:
podman pod inspect
#8021This issue is a placeholder so the slowdown can be investigated and, perhaps, addressed.
The text was updated successfully, but these errors were encountered: