Can one of the admins verify that this patch is reasonable to test? (reply "ok to test", or if you trust the user, reply "add to whitelist")

If this message is too spammy, please complain to ixdy.

@k8s-bot ok to test

Can one of the admins verify that this patch is reasonable to test? (reply "ok to test", or if you trust the user, reply "add to whitelist")

If this message is too spammy, please complain to ixdy.

What is a user going to do with this flag? Mount prop. flags are INCREDIBLY complicated - what behavior do people need that this satisfies?

Our team attempts to containerize flocker with zfs as back-end storage, and containers in the same flocker node need to read/write and share the same mounted volume. Without this flag, the volume mount propagation mode cannot be specified between the host and the container, and then the volume mount of each container would be isolated by namespace from each other.
By default, the flag would be set with empty string and parsed as 'rprivate' in docker.
If someone chooses to use the propagation flag, he should be familiar with shard mount and responsible for the result himself.@thockin

PR needs rebase

@pmorie @swagiaal or whomever is looking at containerized kubelet now that mount.prop is available in Docker. Is the plan to enable shared by default? I don't like this as a facet of our API if we can avoid it.

@thockin besides shared mode, Docker 1.10.0 also supports slave and private mode.
fyi moby/moby#17034

I know what it supports, we've been watching it for a long time :)

My point is that this is a REALLY complicated API feature that 0.001% of
users will ever need, and I'd rather DTRT by default than offer a flag.

On Fri, Feb 5, 2016 at 8:34 AM, Kaffa notifications@github.com wrote:

@thockin https://github.com/thockin besides shared mode, Docker 1.10.0
also support slave and private mode.
fyi moby/moby#17034 http://url

—
Reply to this email directly or view it on GitHub
#20698 (comment)
.

@Kaffa-MY I agree with @thockin that we need to be careful about exposing an API surface for this. Currently the default is private in raw docker.

@Kaffa-MY I'm curious about what your use-case for this is.

Hmm.. I wonder what would be a good way to expose this if not through the API.

Atomic Host has the same use case which is basically containerizing the mount tools so they don't have to be installed on the minimal host.

Is there a way to make this available to volume plugins without putting it in the API ? That way the change can be made to the flocker plugin as I don't think there is a general use case of pod's needing to propagate mounts.

cc/ me

So here's one use-case I can imagine: say that we want to containerize mount operations and we want to run those containers in pods.

Isn't that what Sami said?

I thought the plan was to move all volumes to shared by default
specifically to allow mount helpers, FUSE daemons, and containerized kubelet

On Fri, Feb 5, 2016 at 3:09 PM, Paul Morie notifications@github.com wrote:

So here's one use-case I can imagine: say that we want to containerize
mount operations and we want to run those containers in pods.

—
Reply to this email directly or view it on GitHub
#20698 (comment)
.

@kubernetes/rh-storage @kubernetes/rh-cluster-infra

It is, @thockin, I hadn't seen sami's comment load in the browser window I had this in.

@pmorie I'm containerizing flocker with zfs as backend storage, containers in the same pod, which constitute a whole flocker agent, need to share the same volume and the mount information.
@thockin If the shared were set as the default propagation mode of volume mount and the API were not exposed, how to deal with the situation where isolation is needed?

@Kaffa-MY @thockin

The default propagation mode in docker is private.

PR needs rebase

Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

Otherwise, if this message is too spammy, please complain to ixdy.

This would be VERY valuable to have in v1.4, given all the @kubernetes/sig-cluster-lifecycle work.
It would make it possible to run kubelet as a pod easily, where /var/lib/kubelet has to be a shared mount.

@thockin @pmorie @rootfs Any chance you'd pick it up?
It should be documented it only works with docker; but on the other hand, if we some day want to support rkt fly; it won't be supported by docker.

+1. Would also really appreciate this feature.

@Kaffa-MY Is the full PR including the implementation public?

Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

Otherwise, if this message is too spammy, please complain to ixdy.

+1 for @thockin's comments. Why can't hostpath volumes be mounted as shared by default? Assuming that not all containers will have the privilege to mount filesystems, are there drawbacks to mounting shared by default?

@luxas Regarding "It would make it possible to run kubelet as a pod easily"

Why is kubelet being run as a pod? I don't think this is an operating mode that @kubernetes/sig-node is willing to support.

@vishh Check out self-hosting. It makes a lot of sense.
And running kubelet in a container with a shared mount works really well.
Kubelet in container w/ shared mount != --containerized, which have had problems.

See kubernetes-retired/kube-deploy#189 for ref.
Most of the fails there was due to the version skew (v1.3.4 vs e2e.test v1.4.0 alpha.2)

I guess the main drawback with default shared mounts is that it will be a docker-specific behaviour then. Otherwise, we could leave it as a docker-specific option that user that understand the implications (and the need for --privileged for it to work) could turn on. Perfect for storafe drivers for example.

We might even be able to containerize the storage driver itself, and then kubelet just could pull and use a such Pod for mounting volumes (like we're using overlay network plugins in a daemonset today). cc @pmorie

Yeah. I plan on using it for making a daemonset with cvmfs in it instead of flexvolumes.

Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

Otherwise, if this message is too spammy, please complain to ixdy.

Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

Otherwise, if this message is too spammy, please complain to ixdy.

+1 to #20698 (comment) - this would make it possible to use Cloud SQL proxy's -fuse feature.

@andrewmchen not including implementation, this is just an api proposal

Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message will repeat several times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

This PR hasn't been active in 30 days. It will be closed in 59 days (Nov 27, 2016).

cc @Kaffa-MY @thockin

You can add 'keep-open' label to prevent this from happening, or add a comment to keep it open another 90 days

Either this or #31504 has to be closed. Given that #31504 is more limited in scope, I vote to close this one (no offense). Scream if I got it wrong (typical :)