Update to Fedora 35 + 36 #115
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Cirrus CI build successful. Image ID |
|
Cirrus CI build successful. Image ID |
|
Cirrus CI build successful. Image ID |
|
Cirrus CI build successful. Image ID |
cevich
force-pushed
the
f36_update
branch
2 times, most recently
from
4bcc4ac to
0601c4f
Compare
|
Cirrus CI build successful. Image ID |
cevich
force-pushed
the
f36_update
branch
4 times, most recently
from
f49e560 to
0ae1608
Compare
|
Cirrus CI build successful. Image ID |
cevich
force-pushed
the
f36_update
branch
2 times, most recently
from
a67ee23 to
c47ab0b
Compare
|
Cirrus CI build successful. Image ID |
|
Cirrus CI build successful. Image ID |
|
Cirrus CI build successful. Image ID |
Prior to this commit, Ubuntu VMs were setup with CGroupsV2 enabled. This supported (especially) podman testing to occur with `crun` instead of `runc` + CgroupsV1 which is the default. The opposite was then done for the Fedora N-1 (aka 'prior') VMs, CGroupsV1 was enabled + `runc`. With the change in F36 to a netavark/aardvark-dns network stack from CNI, testing matrices will become additionally complicated if this regime was maintained. Simplify the landscape by reverting the Ubuntu VM setup back to it's default of CGV1 + `runc`. At the same time, restore Fedora 35 to it's default of CGV2 + `crun` (along with Fedora 36). In other words, coverage will apply according to distribution defaults: * Latest Ubuntu: Use CGV1 + `runc` + CNI * Prior Fedora: Use CGV2 + `crun` + CNI * Latest Fedora: Use CGV2 + `crun` + netavark/aardvark-dns Signed-off-by: Chris Evich <[email protected]>
|
Cirrus CI build successful. Image ID |
|
Cirrus CI build successful. Image ID |
Signed-off-by: Chris Evich <[email protected]>
edsantiago
reviewed
Jul 6, 2022
| @@ -61,7 +61,6 @@ INSTALL_PACKAGES=(\ | |||
| zip | |||
| ) | |||
|
|
|||
| # TODO: Remove this when all CI should test with Netavark/Aardvark by default | |||
| EXARG="--exclude=netavark --exclude=aardvark-dns --exclude=cargo --exclude=rust" | |||
There was a problem hiding this comment.
@containers/podman-maintainers I need help understanding this.
Context is: containers/podman#14397. That PR is failing with what looks like the usual using-CNI-with-netavark problem. I'm wondering if this is the cause. If you look at the entire diff of this PR (115), you will see three instances of TODO: Remove this. In two of those instances, both the comment and the EXARG= were removed. In this one, only the comment was removed. It is not clear whether the word "this" refers to the comment or the definition. Did anyone work with @cevich in making this change, and does anyone understand why this exclusion is in place and what the right thing is to do here?
There was a problem hiding this comment.
This may have been on purpose (only removing the comment). This specific script (fedora-netavark_packaging.sh) is only used for building the CI VM images used by netavark & aardvark-dns, nowhere else. For those use-cases, CI is using runtime-produced & installed netavark/aardvark-dns binaries. So we definitely don't want the RPMs installed. I'll double check the other TODO: Remove this in the diff (here) and make sure they're intentional...
There was a problem hiding this comment.
...Ya, the other ones look fine. Sorry for any confusion removal of (only) the comment here caused.
edsantiago
added a commit
to edsantiago/container_automation_images
that referenced
this pull request
Jul 6, 2022
PR containers#115 removed a force-cgroups-v2 setup for Ubuntu, possibly assuming that Ubuntu uses cgroups v1 by default? That doesn't seem to be the case: the Ubuntu I've looked at (via Cirrus rerun-with-terminal) seems to default to v2. End result is that we've been running CI for months without testing runc. This PR forces cgroups v1 on Ubuntu, via grub boot args. Also, remove a confusing "--exclude netavark et al". Again in PR containers#115 the "TODO: remove this" comment was removed but the actual code was not. I believe that was an oversight. Both of these are completely untested. This PR is the test. Signed-off-by: Ed Santiago <[email protected]>
cevich
pushed a commit
to cevich/automation_images
that referenced
this pull request
Jul 18, 2022
PR containers#115 removed a force-cgroups-v2 setup for Ubuntu, possibly assuming that Ubuntu uses cgroups v1 by default? That doesn't seem to be the case: the Ubuntu I've looked at (via Cirrus rerun-with-terminal) seems to default to v2. End result is that we've been running CI for months without testing runc. This PR forces cgroups v1 on Ubuntu, via grub boot args. Also, remove a confusing "--exclude netavark et al". Again in PR containers#115 the "TODO: remove this" comment was removed but the actual code was not. I believe that was an oversight. Both of these are completely untested. This PR is the test. Signed-off-by: Ed Santiago <[email protected]>
cevich
pushed a commit
to cevich/automation_images
that referenced
this pull request
Jul 18, 2022
PR containers#115 removed a force-cgroups-v2 setup for Ubuntu, possibly assuming that Ubuntu uses cgroups v1 by default? That doesn't seem to be the case: the Ubuntu I've looked at (via Cirrus rerun-with-terminal) seems to default to v2. End result is that we've been running CI for months without testing runc. This PR forces cgroups v1 on Ubuntu, via grub boot args. Also, remove a confusing "--exclude netavark et al". Again in PR containers#115 the "TODO: remove this" comment was removed but the actual code was not. I believe that was an oversight. Both of these are completely untested. This PR is the test. Signed-off-by: Ed Santiago <[email protected]>
edsantiago
added a commit
to edsantiago/container_automation_images
that referenced
this pull request
Jul 19, 2022
PR containers#115 removed a force-cgroups-v2 setup for Ubuntu, possibly assuming that Ubuntu uses cgroups v1 by default? That doesn't seem to be the case: the Ubuntu I've looked at (via Cirrus rerun-with-terminal) seems to default to v2. End result is that we've been running CI for months without testing runc. This PR forces cgroups v1 on Ubuntu, via grub boot args. Signed-off-by: Ed Santiago <[email protected]>
edsantiago
added a commit
to edsantiago/container_automation_images
that referenced
this pull request
Jul 19, 2022
PR containers#115 removed a force-cgroups-v2 setup for Ubuntu, possibly assuming that Ubuntu uses cgroups v1 by default? That doesn't seem to be the case: the Ubuntu I've looked at (via Cirrus rerun-with-terminal) seems to default to v2. End result is that we've been running CI for months without testing runc. This PR forces cgroups v1 on Ubuntu, via grub boot args. Signed-off-by: Ed Santiago <[email protected]>
edsantiago
added a commit
to edsantiago/container_automation_images
that referenced
this pull request
Jul 19, 2022
PR containers#115 removed a force-cgroups-v2 setup for Ubuntu, possibly assuming that Ubuntu uses cgroups v1 by default? That doesn't seem to be the case: the Ubuntu I've looked at (via Cirrus rerun-with-terminal) seems to default to v2. End result is that we've been running CI for months without testing runc. This PR forces cgroups v1 on Ubuntu, via grub boot args. Signed-off-by: Ed Santiago <[email protected]>
edsantiago
added a commit
to edsantiago/container_automation_images
that referenced
this pull request
Jul 20, 2022
PR containers#115 removed a force-cgroups-v2 setup for Ubuntu, possibly assuming that Ubuntu uses cgroups v1 by default? That doesn't seem to be the case: the Ubuntu I've looked at (via Cirrus rerun-with-terminal) seems to default to v2. End result is that we've been running CI for months without testing runc. This PR forces cgroups v1 on Ubuntu, via grub boot args. Signed-off-by: Ed Santiago <[email protected]>
edsantiago
added a commit
to edsantiago/container_automation_images
that referenced
this pull request
Jul 20, 2022
PR containers#115 removed a force-cgroups-v2 setup for Ubuntu, possibly assuming that Ubuntu uses cgroups v1 by default? That doesn't seem to be the case: the Ubuntu I've looked at (via Cirrus rerun-with-terminal) seems to default to v2. End result is that we've been running CI for months without testing runc. This PR forces cgroups v1 on Ubuntu, via grub boot args. Signed-off-by: Ed Santiago <[email protected]>
edsantiago
added a commit
to edsantiago/container_automation_images
that referenced
this pull request
Jul 20, 2022
PR containers#115 removed a force-cgroups-v2 setup for Ubuntu, possibly assuming that Ubuntu uses cgroups v1 by default? That doesn't seem to be the case: the Ubuntu I've looked at (via Cirrus rerun-with-terminal) seems to default to v2. End result is that we've been running CI for months without testing runc. This PR forces cgroups v1 on Ubuntu, via grub boot args. Signed-off-by: Ed Santiago <[email protected]>
edsantiago
added a commit
to edsantiago/container_automation_images
that referenced
this pull request
Jul 20, 2022
PR containers#115 removed a force-cgroups-v2 setup for Ubuntu, possibly assuming that Ubuntu uses cgroups v1 by default? That doesn't seem to be the case: the Ubuntu I've looked at (via Cirrus rerun-with-terminal) seems to default to v2. End result is that we've been running CI for months without testing runc. This PR forces cgroups v1 on Ubuntu, via grub boot args. Signed-off-by: Ed Santiago <[email protected]>
edsantiago
added a commit
to edsantiago/container_automation_images
that referenced
this pull request
Jul 20, 2022
PR containers#115 removed a force-cgroups-v2 setup for Ubuntu, possibly assuming that Ubuntu uses cgroups v1 by default? That doesn't seem to be the case: the Ubuntu I've looked at (via Cirrus rerun-with-terminal) seems to default to v2. End result is that we've been running CI for months without testing runc. This PR forces cgroups v1 on Ubuntu, via grub boot args. Signed-off-by: Ed Santiago <[email protected]>
edsantiago
added a commit
to edsantiago/container_automation_images
that referenced
this pull request
Jul 20, 2022
PR containers#115 removed a force-cgroups-v2 setup for Ubuntu, possibly assuming that Ubuntu uses cgroups v1 by default? That doesn't seem to be the case: the Ubuntu I've looked at (via Cirrus rerun-with-terminal) seems to default to v2. End result is that we've been running CI for months without testing runc. This PR forces cgroups v1 on Ubuntu, via grub boot args. Signed-off-by: Ed Santiago <[email protected]>
edsantiago
added a commit
to edsantiago/container_automation_images
that referenced
this pull request
Jul 20, 2022
PR containers#115 removed a force-cgroups-v2 setup for Ubuntu, possibly assuming that Ubuntu uses cgroups v1 by default? That doesn't seem to be the case: the Ubuntu I've looked at (via Cirrus rerun-with-terminal) seems to default to v2. End result is that we've been running CI for months without testing runc. This PR forces cgroups v1 on Ubuntu, via grub boot args. As of 2022-07-20 the version of criu in Ubuntu is broken, which requires us to install from something called OBS. There was some OBS-installing code present, but it didn't lend itself to reuse, so I refactored it and added a temporary use-criu-from-obs line with a timestamped FIXME. Signed-off-by: Ed Santiago <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ref: https://dl.fedoraproject.org/pub/fedora/linux/development/36/Cloud/x86_64/images/