CI: mount tmpfs for container storage #22831
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Luap99 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Ephemeral COPR build failed. @containers/packit-build please check. |
Given my other speed up PRs it is hard to have a solid baseline and looking at several PR's the timings seems to vary by several minutes between runs so I cannot say for certain if it is faster, if it is then not by much so not sure if it is worth it? @edsantiago WDYT? |
|
Sorry for taking so long. Can you hold off on this for a little while? Specifically: hold off on anything that increases any use of tmpfs? I've been observing an ENOSPC flake in #17831, only in e2e, and I think it might be due to multiple disk-hog tests running at once. Haven't looked deeply enough, and am not likely to do so soon. I'd like to understand that one before we keep piling onto tmpfs. (In case it's not obvious, the reason it only happens in #17831 is because it disables flake retries. I am confident that it is happening in real-world PRs but we don't see it because the ginkgo flake-retry mechanism hides it). |
|
Sure all I wanted to know if it makes a measurable difference, so far it does not like it so I have no good reason to push for this. |
|
Thanks. I still think this is worth pursuing (potentially). The noise in sys tests bothers me. I understand noise in e2e tests: flake retries, parallelization load differences. But sys tests I would expect to be more consistent. |
|
A friendly reminder that this PR had no activity for 30 days. |
|
@edsantiago Are you fine with me pushing this forward? |
|
LGTM |
|
Yes, let's try it. Please rebase and remove the WIP. |
Try to speed up the CI tests by using tmpfs as container storage. This is important for system tests, other tests setup their own --root already on tmpfs so it should not effect them. Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The test check the the default volume is not on tmpfs, however what it should really check that the volume is on our container storage fs. It is possible that users run the storage on top of tmpfs so this test always failed there. The better check is to compare the fs from the graphroot and the volume. Unfortunately, for unknown reasons stat -f -c %T returns UNKNOWN and not the actual fs. I have no idea why, to work around that we now parse /proc/mounts manually for the fs. Not nice but at least it works correctly. Signed-off-by: Paul Holzinger <pholzing@redhat.com>
|
@edsantiago Good to merge like this? |
|
Sure... worth a try /lgtm (may need to be merged manually) |
d1a258b
into
containers:main
Try to speed up the CI test by using tmpfs as container storage.
No idea if this works or will make a measurable difference but let's find out.
Does this PR introduce a user-facing change?