Skip to content
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

[release-1.30] userns: Skip tests if the host doesn't support idmap mounts #1492

Merged

Conversation

saschagrunert
Copy link
Member

What type of PR is this?

/kind failing-test

What this PR does / why we need it:

Cherry-pick of #1489 into release-1.30.

Which issue(s) this PR fixes:

None

Special notes for your reviewer:

cc @rata

Does this PR introduce a user-facing change?

Skip tests with idmap mounts on host that don't support it.

rata added 3 commits July 10, 2024 09:21
critest is used in projects like containerd, that test against older
distros (like AlmaLinux 8). In those distros, CI will fail when we
upgrade to runc 1.2.0.

With runc 1.1 those test don't fail because runc doesn't support idmap
mounts and the tests are skipped in that case. But with runc 1.2.0-rc.2,
that supports idmap mounts, the tests are not skipped but fail on
distros with older kernels that don't support idmap mounts.

This commit just tries to detect if the path used for the container
rootfs supports idmap mounts. To do that it uses the Status() message
from CRI with verbose param set to true. It parses the output that
containerd sets (it's quite unspecified that field), and otherwise
fallbacks to "/var/lib" as the path to test idmap mounts support.

Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
Sascha suggested to run this only once. Let's cache the answer from the
runtime and move the tests that need idmap mounts on the host to
`When("Host idmap mount support is needed"`.

While we split the tests in that way, let's just query idmap mount
support for the tests that need it, using the cache.

Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
containerd creates a userns and inside there, it runs the critest tool.
However, in that setup, the length of containerd's userns is not the
whole UID space.

Let's verify that the length of the userns inside the pod, when we
created it with NamespaceMode_NODE (IOW, when not using a new userns for
the pod) is the same as outside the pod.

This works fine when contained itself runs inside a userns.

Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
@k8s-ci-robot k8s-ci-robot added kind/failing-test Categorizes issue or PR as related to a consistently or frequently failing test. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Jul 10, 2024
@k8s-ci-robot k8s-ci-robot added approved Indicates a PR has been approved by an approver from all required OWNERS files. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jul 10, 2024
Copy link
Contributor

@rata rata left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@k8s-ci-robot
Copy link
Contributor

@rata: changing LGTM is restricted to collaborators

In response to this:

LGTM, thanks!

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@rata
Copy link
Contributor

rata commented Jul 10, 2024

The windows fail seem unrelated to this PR, the failing test are not changed here.

@rata
Copy link
Contributor

rata commented Jul 10, 2024

The mac job seems stalled, it's not starting and running for 2hs30m:

Requested labels: macos-11
Job defined at: kubernetes-sigs/cri-tools/.github/workflows/build.yml@refs/pull/1492/merge
Waiting for a runner to pick up this job...

@saschagrunert
Copy link
Member Author

The mac job seems stalled, it's not starting and running for 2hs30m:

Requested labels: macos-11
Job defined at: kubernetes-sigs/cri-tools/.github/workflows/build.yml@refs/pull/1492/merge
Waiting for a runner to pick up this job...

Yeah, I can incorporate the fix to make CI happy.

Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
@rata
Copy link
Contributor

rata commented Jul 10, 2024

Thanks! And it worked, all tests green now :)

@saschagrunert
Copy link
Member Author

@kubernetes-sigs/cri-tools-maintainers PTAL

@kwilczynski
Copy link
Member

/approve
/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jul 11, 2024
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kwilczynski, rata, saschagrunert

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot merged commit b633b38 into kubernetes-sigs:release-1.30 Jul 11, 2024
23 checks passed
@saschagrunert saschagrunert deleted the release-1.30-userns branch July 11, 2024 11:54
@rata rata mentioned this pull request Jul 12, 2024
21 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/failing-test Categorizes issue or PR as related to a consistently or frequently failing test. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants