Private mount propagation

[jsafrane]

This PR changes the default mount propagation from "rslave" (newly added in 1.10) to "private" (default in 1.9 and before). "rslave" as default causes regressions, see below.

Value "None" has to be added to MountPropagationMode enum in API ("I don't want any propagation at all"), which translates to "private" on Linux. We did not have use cases for it, but we have them now.

Which issue(s) this PR fixes
Fixes #62397, fixes #62396

Special notes for your reviewer:
CRI already has an option for private mount propagation in volumes, however it's called "PRIVATE", while Kubernetes API value is "None". I did not change PRIVATE to NONE to keep the interface stable. See kubelet_pods.go.

Release note:

Default mount propagation has changed from "HostToContainer" ("rslave" in Linux terminology) to "None" ("private") to match the behavior in 1.9 and earlier releases. "HostToContainer" as a default caused regressions in some pods.

/sig storage
/sig node

[jsafrane]

@thockin, please look at the API.

@tallclair, can I ask you to look at kubelet changes? Thanks! FYI, the ultimate plan is to cherry-pick it to 1.10.x, i.e. we're changing the default behavior in patch release. I consider it to be a bugfix.

[saad-ali]

/lgtm
/approve

For API review:
/assign @thockin

[saad-ali]

@thockin is out-of-office. Can we get @smarterclayton to review/approve API changes?

[jsafrane]

@liggitt, as @thockin is on PTO these days, would you mind approving the API change and validation?

[liggitt]

@kubernetes/sig-storage-api-reviews

[liggitt]

IIUC, this API field was added in 1.10, and this is adding an additional allowed value that matches the default behavior in 1.9, and making it the default when the field is unspecified?

do you plan to pick this to 1.10.x as well?

[jsafrane]

IIUC, this API field was added in 1.10, and this is adding an additional allowed value that matches the default behavior in 1.9, and making it the default when the field is unspecified?

Yes

do you plan to pick this to 1.10.x as well?

Yes! That's the goal.

[liggitt]

/lgtm

[derekwaynecarr]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: derekwaynecarr, jsafrane, liggitt, saad-ali

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:

• pkg/apis/core/OWNERS [liggitt]
• pkg/kubelet/OWNERS [derekwaynecarr]
• staging/src/k8s.io/api/OWNERS [liggitt]
• test/e2e/node/OWNERS [derekwaynecarr,liggitt,saad-ali]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-github-robot]

/test all [submit-queue is verifying that this PR is safe to merge]

[k8s-github-robot]

Automatic merge from submit-queue (batch tested with PRs 60476, 62462, 61391, 62535, 62394). If you want to cherry-pick this change to another branch, please follow the instructions here.

[k8s-ci-robot]

@jsafrane: The following tests failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
pull-kubernetes-kubemark-e2e-gce	a943fdd	link	/test pull-kubernetes-kubemark-e2e-gce
pull-kubernetes-node-e2e	a943fdd	link	/test pull-kubernetes-node-e2e
pull-kubernetes-verify	a943fdd	link	/test pull-kubernetes-verify

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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. I understand the commands that are listed here.