-
Notifications
You must be signed in to change notification settings - Fork 39.9k
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
Don't guess SELinux support on error #105934
Conversation
@jsafrane: This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The 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/test-infra repository. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jsafrane 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 |
When GetSELinuxSupport() fails, don't assume a mounted filesystem does not support SELinux at all. Try again instead in the next SetUp retry. This may hurt performance a bit, since kubelet will call NodePublishVolume again, but it's better than providing wrong information to the container runtime that will then skip relabeling of the volume.
722d99f
to
186810e
Compare
/lgtm |
The Kubernetes project has merge-blocking tests that are currently too flaky to consistently pass. This bot retests PRs for certain kubernetes repos according to the following rules:
You can:
/retest |
1 similar comment
The Kubernetes project has merge-blocking tests that are currently too flaky to consistently pass. This bot retests PRs for certain kubernetes repos according to the following rules:
You can:
/retest |
@@ -276,7 +276,8 @@ func (c *csiMountMgr) SetUpAt(dir string, mounterArgs volume.MounterArgs) error | |||
|
|||
c.supportsSELinux, err = c.kubeVolHost.GetHostUtil().GetSELinuxSupport(dir) | |||
if err != nil { | |||
klog.V(2).Info(log("error checking for SELinux support: %s", err)) | |||
// The volume is mounted. Return UncertainProgressError, so kubelet will unmount it when user deletes the pod. | |||
return volumetypes.NewUncertainProgressError(fmt.Sprintf("error checking for SELinux support: %s", err)) | |||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this will cause regression in environments that don't even have selinux enabled. Could we check if host supports selinux before even querying mount info, so as hosts that don't support selinux do not incur the potential overhead of reading mount table?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a check for SELinux support in the OS via pkg/util/selinux.SELinuxEnabled`, which should be cached after the first invocation.
Putting on hold to address comment above. /hold |
Skip parsing of /proc/mounts if SELinux is disabled on the machine.
Previously, an error from GetSELinuxSupport was treated as a filesystem did not support SELinux. Now the error is treated separately.
Added SELinux detection + fixed unit tests not to return error from GetSELinuxSupport. |
/hold cancel |
/retest |
/priority important-soon |
…5934-upstream-release-1.20 Automated cherry pick of #105934: Don't guess SELinux support on error
…5934-upstream-release-1.21 Automated cherry pick of #105934: Don't guess SELinux support on error
…5934-upstream-release-1.22 Automated cherry pick of #105934: Don't guess SELinux support on error
When
GetSELinuxSupport()
fails, don't assume a mounted filesystem does not support SELinux at all. Try again instead in the nextSetUp
retry.This may hurt performance a bit, since kubelet will call
NodePublishVolume
again, but it's better than providing wrong information to the container runtime that will then skip relabeling of the volume.What type of PR is this?
/kind bug
Which issue(s) this PR fixes:
Fixes #105933
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: