Bug 1861526 - FSGroup e2e test added in 1.19 fails consistently on openshift
Summary: FSGroup e2e test added in 1.19 fails consistently on openshift
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Node
Version: 4.6
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.6.0
Assignee: Seth Jennings
QA Contact: Weinan Liu
Depends On:
TreeView+ depends on / blocked
Reported: 2020-07-28 20:53 UTC by Maru Newby
Modified: 2020-09-07 07:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Github openshift origin pull 25414 None closed Bug 1861526: test: extended: reenable service account test disabled during rebase 2020-09-07 02:26:41 UTC

Description Maru Newby 2020-07-28 20:53:36 UTC
The following test added upstream in 1.19 fails consistently against openshift:

[sig-auth] ServiceAccounts should set ownership and permission when RunAsUser or FsGroup is present [LinuxOnly] [NodeFeature:FSGroup] [Feature:TokenRequestProjection] [Suite:openshift/conformance/parallel] [Suite:k8s]

Added in: https://github.com/kubernetes/kubernetes/pull/89193
Example of failure: https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/25314/pull-ci-openshift-origin-master-e2e-aws-fips/1288149961694777344

This test is skipped in origin's rule.go until a fix is available.

Comment 1 Maru Newby 2020-07-28 20:54:44 UTC
Failure mode: Test passes but AfterSuite fails due to the container it uses exiting non-zero.

Comment 2 Seth Jennings 2020-08-13 16:56:32 UTC
failure context

Output of node "ip-10-0-153-213.ec2.internal" pod "test-pod-5c0eadb2-cadc-4bfe-83af-f1f4bd460e5c" container "test-container":
perms of file "/test-volume/token": -rw-------
owner UID of "/test-volume/token": 0
owner GID of "/test-volume/token": 0
error reading file content for "/test-volume/token": open /test-volume/token: permission denied

expected (hard to tell since the individual test cases don't have names but I think it is the first one):


perms of file "/test-volume/token": -rw-------
owner UID of "/test-volume/token": 1000
owner GID of "/test-volume/token": 0
content of file "/test-volume/token": <token>

seems the issue is the UID of the token volume is not set as expected (0 instead of 1000)

for this test case pod.Spec.SecurityContext.RunAsUser is set to 1000 and pod.Spec.SecurityContext.FSGroup is not set

Comment 3 Seth Jennings 2020-08-13 17:01:09 UTC
Just ran against my own 4.6 cluster and the test passes.  Possible a transient skew issue during the rebase.  Re-enabling the test.

Comment 6 Weinan Liu 2020-09-07 07:07:27 UTC
Issue got fixed basing on comment #3

Note You need to log in before you can comment on or make changes to this bug.