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. On Oct 26, 2016 9:53 PM, "Clayton Coleman" <ccole...@redhat.com> wrote: > 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 <mpa...@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 <je...@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 <vish...@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 <je...@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: >>>>> ​http://developerblog.redhat.com/2016/10/25/docker-project-c >>>>> an-you-have-overlay2-speed-and-density-with-devicemapper-yep/ >>>>> >>>>> 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. >>>>> >>>>> https://twitter.com/rhdevelopers/status/790870667008757760 >>>>> >>>>> -- >>>>> 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+unsubscr...@googlegroups.com. >>>>> To post to this group, send email to kubernetes-...@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 >>>>> <https://groups.google.com/d/msgid/kubernetes-dev/CABxNGQa-VLzP%3DEFYQucfJtTEtSHmWac4Tv%3Dc%2BQVAFJNcDLSb1g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> 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+unsubscr...@googlegroups.com. >> To post to this group, send email to kubernetes-...@googlegroups.com. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/kubernetes-dev/CANEZBD4zd%3Dk-m2B2rK5Eixv_%2BfY3tFqSgJa% >> 2BaemW4f4fj5g3Bg%40mail.gmail.com >> <https://groups.google.com/d/msgid/kubernetes-dev/CANEZBD4zd%3Dk-m2B2rK5Eixv_%2BfY3tFqSgJa%2BaemW4f4fj5g3Bg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > >
