I have a serious question about a way to map UIDs inside the container to UIDs outside it. And a way to specify UID for mounted volumes like /data/ and /app/code/
Let's look to the topic from developer point of view.
I have vagrant sshfs mouting my home into the box.
My home have volumes owned by me with uid=1001. Also it have my ide and my code.
I have a container that have a user called app with uid=1000 and have an old clone in /app/code/
I'm mounting /home/ali/volumes/proj1 into /data/
And sometimes /home/ali/workspace/proj1 into /app/code
The problem is we can't specify uid of those mounts inside the containers.
One way is to sed /etc/passwd to change uid of the in container app user
But in that case we need to chmod /app/code from old uid before sed to new one.
Which require writable container.
The otherway is to keep app uid as is but to chown /data (passed from outside) to uid 1000 (app) which would create a problem outside.
If we can specify uid when mounting that would solve the problem.
Yeah it sounds like it - that's a good place to start, and then if we realize we need the knob we can come back and decide on an API object change if necessary.On Wed, Oct 26, 2016 at 2:46 PM, Mrunal Patel <mpatel redhat com> wrote:IMO, this doesn't really need any new knobs in the pod spec. This could be handled under the hood in the container runtime level (by config or default).--On Wed, Oct 26, 2016 at 11:44 AM, Jeremy Eder <jeder redhat com> wrote:If a user specifies read-only in their podspec...what does that translate to (it might be a distro-specific question). IMO the --shared-rootfs should be the default when --read-only is specified, but it's not atm.Vivek has implemented it for devicemapper first. But the intent is that it will be added to most or all graph drivers, including overlay/overlay2. It has the most benefit on devicemapper or btrfs which have unique inodes per container.--On Wed, Oct 26, 2016 at 2:20 PM, Vishnu Kannan <vishnuk google com> wrote:*What* do you intend to surface to users? IIUC, this discussion is specific to device mapper storage drivers right?On Tue, Oct 25, 2016 at 5:03 AM, Jeremy Eder <jeder redhat com> wrote:--Hi,Vivek Goyal (cc) and I were discussing ways to deliver page cache sharing, POSIX compliance and SELinux support with a single docker graph driver, using existing kernel facilities. We decided to go with a bind-mount technique, and Vivek has posted a first cut here: https://github.com/docker/docker/pull/27364 Testing of the prototype looks like a great improvement:Assuming this type of feature is merged in a container run-time, what preference would Kube folks have for surfacing this to users ... currently it's a daemon runtime flag that says ... if you use --read-only then you get the shared-rootfs as well. Obviously this requires "12factor-ish" design up front, because you can no longer scribble in the container filesystem in places that are not persistent volumes, but we think read-only container hygiene is well worth the security and performance improvements to be had.
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe googlegroups.com .
To post to this group, send email to kubernetes-dev googlegroups com .
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CABxNGQa-VL .zP%3DEFYQucfJtTEtSHmWac4Tv%3Dc %2BQVAFJNcDLSb1g%40mail.gmail. com
For more options, visit https://groups.google.com/d/optout .
-- Jeremy Eder
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe googlegroups.com .
To post to this group, send email to kubernetes-dev googlegroups com .
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CANEZBD4zd% .3Dk-m2B2rK5Eixv_%2BfY3tFqSgJa% 2BaemW4f4fj5g3Bg%40mail.gmail. com