-
Notifications
You must be signed in to change notification settings - Fork 794
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
Cirrus: Bump up to Fedora 35 & Ubuntu 21.10 #3599
Conversation
@nalind @edsantiago Sn F35 some "No Op" test is timing out after 45minutes. Sorry I don't know the unit-tests well at all, so am not sure where to even begin looking. Would you mind taking a peek and advising what/where needs fixing by whom? |
I tried, but this failure is beyond me. Sorry. |
|
Thanks for taking a look @edsantiago At the VM-image level, the only other case where I've seen something completely hang, is with the podman bindings test. Ironically, also during a build-test. @nalind is there anything I can do to help get this fixed? Odd that it would only affect F35, is Edit: Ref: podman bindings build test failure logs |
I've managed to narrow it down to an interaction between something that changes based on how we build the statically-linked unit test helper, which the unit tests invoke to ensure that chroot isolation at least does the things we think it does, and the seccomp filter which the tests use when they invoke the unit test helper, which hasn't been the same as what we use outside of unit tests for a while now. Switching from using the external linker to statically link the helper to letting the Go compiler use its internal linker seems to work around it, somehow, but the tests could always stand to be a better reflection of how things work outside of the tests, so I'm going to try that first. Can you cherry-pick the tip of https://github.com/nalind/buildah-1/tree/chroot-unit-test-seccomp branch into this PR and see if that helps? It does for me on my mostly-F35 box. |
Good, yes, I'm almost always in favor of spending more time to fix it right, rather than constantly worry forever. And thanks for going deep, that's some black-magic-voodoo you dug up, I can't even spell half those words! Yes, happy to cherry-pick, and of course you're welcome to temporarily rebase off this PR too. Please let me know if there's any other ways I can help. |
@nalind that seems to have done the trick. |
@cevich is this still a draft or ready to merge? |
Thanks for checking, yes it's still a draft. It's using a F35beta image whereas it's actually been released now. I'll update this PR again once the podman one is ready to go, so we can keep common image-IDs across the projects (helpful for debugging). |
3740488
to
6c9a250
Compare
@nalind were you going to make a separate PR for your 'chroot-unit-test-seccomp' branch, or should I just include it here? |
Feel free to pull it in if it makes things simpler. |
I think it does, just wasn't sure if you wanted to have scrutiny beyond this PR. Seems like the fix works, so 🤷♂️ we can run with it. For this PR in general, the status is same as I said a few days ago: I'd like to wait until we get green-lights on the podman-side simply out of convenience to share the same image. My plan is to open similar PRs for all the other container repos. at that time as well. |
8335c09
to
9e14fed
Compare
1be0677
to
e6ef919
Compare
Is this still a WIP? |
Only barely. I can un-WIP it if it's needed right now...but I think having the podman tests actually pass adds a bit more confidence the images are safe to use elsewhere. I'm not going to press that as a hard requirement though. |
When we link our test helper statically using the external linker, the hardwired default seccomp filter we get from the runtime-tools generator triggers a hang in it at startup. Rather than switch to the internal linker, which seems to work around this, start using the same seccomp filter for unit tests that we actually use in real life, leaving analysis of which difference between the two is responsible for it for another day. Signed-off-by: Nalin Dahyabhai <[email protected]>
The Fedora 35 cloud images have switched to UEFI boot with a GPT partition. Formerly, all Fedora images included support for runtime re-partitioning. However, the requirement to test alternate storage has since been dropped/removed. Rather than maintain a disused feature, and supporting scripts, these Fedora VM images have reverted to the default: Automatically resize to 100% on boot. Signed-off-by: Chris Evich <[email protected]>
e6ef919
to
0b3e75a
Compare
Rebased / force-pushed / un-WIP/draft the PR. Assuming it passes, please merge if there is a need and/or containers/podman#11795 gets merged - whichever happens first 😄 |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cevich, rhatdan 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 |
What type of PR is this?
/kind other
What this PR does / why we need it:
The Fedora 35 cloud images have switched to UEFI boot with a GPT
partition. Formerly, all Fedora images included support for runtime
re-partitioning. However, the requirement to test alternate storage
has since been dropped/removed. Rather than maintain a disused
feature, and supporting scripts, these Fedora VM images have reverted
to the default: Automatically resize to 100% on boot.
How to verify it
CI testing will pass
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
Please wait for containers/podman#11795 to merge first.
Does this PR introduce a user-facing change?
None