After some thought, I realize that if we do this, there's really no need for #19762

So the biggest issue with this is that updating a file atomically across a
namespace is practically impossible. You have to enter the target
namespace to really do it right.

I'd love to see this be possible, so it is probably worth exploring, but I
think it HAS to support atomic updates properly if updates are supported at
all.

On Sat, Jan 16, 2016 at 11:37 AM, Paul Morie notifications@github.com
wrote:

This issue is to explore the possibility of allowing users to make
projections of individual files from volumes into a container. Example
use-case is where the user wants to place volume content into an existing
directory without mounting over the existing contents of that directory.
Example: say you want to project a file into /etc/ssl/certs without
making the other files in that directory inaccessible.

@mfojtik https://github.com/mfojtik This is your use-case -- feel free
to elaborate.

@thockin https://github.com/thockin @smarterclayton
https://github.com/smarterclayton @bgrant0607
https://github.com/bgrant0607 @saad-ali https://github.com/saad-ali
@kubernetes/rh-storage
https://github.com/orgs/kubernetes/teams/rh-storage

—
Reply to this email directly or view it on GitHub
#19764.

@pmorie thanks! another use-case we have is to add files like .npmrc into $HOME or to /etc. This file contains internal URL to nodejs mirror and credentials (user+pass). This file is needed during the build time and not needed in output image (so having a way to 'unplug' the file from the contains would be nice to have as well ;-)

@thockin I think the update to secret content should trigger restart of the container where the secret is projected to.

This is a point of debate for secrets. DownwardAPI already allows dynamic
refresh, and config map is not done yet.
On Jan 17, 2016 12:55 AM, "Michal Fojtik" notifications@github.com wrote:

@thockin https://github.com/thockin I think the update to secret
content should trigger restart of the container where the secret is
projected to.

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

Some applications expect configuration files directly in /etc. This would be useful for such cases.

Yes, we need atomic updates for some cases.

I think this is also solvable with pre-start hooks

Apps that NEED it in /etc/foo.conf can provide an image that symlinks
/etc/foo.conf -> /vol/etc/foo.conf.

I'm not against this feature, I think it would be great, I just don't think
the implementation (at least the one I know how to do) is justified, when a
relatively easy workaround is present.

On Thu, Jan 21, 2016 at 12:53 PM, Paul Morie notifications@github.com
wrote:

I think this is also solvable with pre-start hooks

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

@thockin Agree, if you really want this, you can have it without a kube feature.

@mfojtik How do you feel about setting up symlinks in the container entrypoint, does that get you any closer to where you want to be?

Changing the image is actually a fairly involved process - the statement we
make in other places is that adaptation of existing images to run is useful
and justifies some additional complexity on our end to make easy.
Individual file projection is useful in some cases, and less useful in
others. As someone who has done the symlinking thing, it's error prone,
annoying to do, and you end up doing it in a lot of images (if you have
more than 2 you care about). So there's some value in having a bit more
complexity. I don't know that it's required right now

On Fri, Jan 22, 2016 at 11:46 AM, Paul Morie notifications@github.com
wrote:

@thockin https://github.com/thockin Agree, if you really want this, you
can have it without a kube feature.

@mfojtik https://github.com/mfojtik How do you feel about setting up
symlinks in the container entrypoint, does that get you any closer to where
you want to be?

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

I agree this would be a great feature, I don't think it is "a bit more
complexity", though. If someone wants to prototype it, I'm happy to brain
dump (or just go look at moby/moby#17190)

On Fri, Jan 22, 2016 at 10:10 AM, Clayton Coleman notifications@github.com
wrote:

Changing the image is actually a fairly involved process - the statement we
make in other places is that adaptation of existing images to run is useful
and justifies some additional complexity on our end to make easy.
Individual file projection is useful in some cases, and less useful in
others. As someone who has done the symlinking thing, it's error prone,
annoying to do, and you end up doing it in a lot of images (if you have
more than 2 you care about). So there's some value in having a bit more
complexity. I don't know that it's required right now

On Fri, Jan 22, 2016 at 11:46 AM, Paul Morie notifications@github.com
wrote:

@thockin https://github.com/thockin Agree, if you really want this,
you
can have it without a kube feature.

@mfojtik https://github.com/mfojtik How do you feel about setting up
symlinks in the container entrypoint, does that get you any closer to
where
you want to be?

—
Reply to this email directly or view it on GitHub
<
#19764 (comment)

.

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

A customer had a narrower problem which might have a more direct solution -- no sure if it is worthwhile.
The customer wanted to have secrets A and B, each with one key, say "file-a" and "file-b". The customer wanted to mount them at "/etc/secrets/file-a" and "/etc/secrets/file-b". I suppose we could recognize this specific case at kubelet and merge the keys into a single combined volume prior to mounting. But, there are probably enough sharp corners that I'm not sure this is worthwhile. Also, explaining what is and isn't supported would get harder.

Options I see:

a) do the really complicated process for updating a file-projection (enter
target namespace...)

b) document that single-file projections are not live-updatable

c) document the (user-driven) workaround of making an image with
/etc/secret-a be a symlink -> /mnt/secrets/a

d) unpack the volume image ourselves and reconstruct the parent dir and
mount the whole dir (likely to break in other ways, e.g. docker commit)

e) convince upstream kernels to support bind-mounting symlinks as symlinks
(without dereference) This is a good answer if we can take a long view
(though it may be a nonstarter, I don't know kernel VFS that well)

On Fri, Feb 12, 2016 at 11:24 AM, Eric Tune notifications@github.com
wrote:

A customer had a narrower problem which might have a more direct solution
-- no sure if it is worthwhile.
The customer wanted to have secrets A and B, each with one key, say
"file-a" and "file-b". The customer wanted to mount them at
"/etc/secrets/file-a" and "/etc/secrets/file-b". I suppose we could
recognize this specific case at kubelet and merge the keys into a single
combined volume prior to mounting. But, there are probably enough sharp
corners that I'm not sure this is worthwhile. Also, explaining what is and
isn't supported would get harder.

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

I'm running into an issue right now where I'm trying to reuse an existing nodejs application which insists on reading a config.js file from it's application root directory. I was really hoping I could use a secret or configmap to inject the single config.js file and avoid "hiding" the application directory, but that does not work.

So yeah, this would be a really nice feature.

It is not sufficient or workable to build the image with the file being a symlink to an empty dir, and let secret or configmap mount into the dir? Not that I don't want this feature, but I want to see the f we can unblock people.

I know that @derekwaynecarr also had this problem. openshift expects certs and config files to live next to each other in the same directory. Yes, his problem is 'solvable'/'work-arround-able' by creating a custom image with symlinks. But custom images come with their own pain when the original image is updated.

@smarterclayton @eparis @thockin Why not have an all-in-one volume for this for the time being?

The all-in-one was really ugly, I thought. I guess I am not really against it, it just feels clumsier than it should be. any other answer I have come up with is uglier, though. Still doesn't solve the as-a-file case.

it does work, now, but no updates

Does it? I could not figure out how. If I have an app that expects a config file in /app.conf or /app/conf/app.conf, what syntax do I use to mount the configmap as the single file app.conf without mounting over the entire / or /app/conf/?

Well, it looks like I figured it out here dshulyak/kubernetes.github.io@d58ba7b

but that was a lot harder to find than it should have been.

getting @deitch's example into the ConfigMap docs would be nice.

I'm using ployst/nginx-ssl-proxy which looks for all its secrets in /etc/secrets. This worked fine when I just had secrets coming from one place (the letsencrypt container), but now that I want to add basic auth, things get complicated. I first tried:

command: ["/bin/sh", "-c", "ln -s /etc/auth/htpasswd /etc/secrets/htpasswd && ./start.sh"

I wasn't able to mount the cert secrets to /etc/secrets and then just symlink the auth secret. The symlink command would run successfully, but when the container started the htpasswd file would be gone. If I then exec -it [pod] /bin/bash I can manually run the symlink command and the file persists. This makes me think that maybe a volume refresh is being triggered during the container finalization lifecycle. Speculation though - there's really no evidence of what happened.

I ended up mounting both of my secrets to separate locations, then symlinking all the files I need:

command: ["/bin/sh", "-c", "mkdir -p /etc/secrets && \
                            ln -s /etc/certs/dhparam /etc/secrets/dhparam && \
                            ln -s /etc/certs/proxycert /etc/secrets/proxycert && \
                            ln -s /etc/certs/proxykey /etc/secrets/proxykey && \
                            ln -s /etc/auth/htpasswd /etc/secrets/htpasswd && \
                            ./start.sh"

It's an unfortunate amount of jumping through hoops though.

It's an unfortunate amount of jumping through hoops though

Bit of a theme....

@bitmage if you can boil down a repro, we can look into it. Naively, I would expect what you described to work...

@jingxu97 @saad-ali

facing same issue, any officially suggested workarounds for this problem?

nm found it!

@debianmaster Care to share the official response that you found?

Just spend several minutes searching for a solution, found it here: #23748 (comment)

you need to supply the absolute path including the filename in the mountPath and the filename again in subPath. The filename (obviously) needs to match the key in your config map.

@schmitzhermes @fearphage sorry for not getting back. you have the right solution @schmitzhermes it wont work from cli though if you have more than 1 file to mount in the same directory. i.e. only works for 1 file

@schmitzhermes unfortunately, as I can see, configmap can't be updated when subPath is defined :(

+1 cry every time,any plans for single file volume mapping?

Any news? hit the same wall

This becomes an even bigger issue when you widely enable restricted psps that don't allow for rootfs writes.... which we did last week.

In this case I need to mount hostpath:/etc/machine-id into container:/etc/machine-id ... I clearly can't just replace container:/etc w/ hostpath:/etc

I'd love to see this get worked on, but it needs an owner. I'm happy to reopen if someone wants to tackle it..

@thockin what would implementing this take? I saw you mention in one of the related issues that it's technically hard to do.