Kubernetes version (use kubectl version):
Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.4", GitCommit:"9befc2b8928a9426501d3bf62f72849d5cbcd5a3", GitTreeState:"clean", BuildDate:"2017-11-20T05:28:34Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2", GitCommit:"5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState:"clean", BuildDate:"2018-01-18T09:42:01Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
Environment: desktop/workstation and server/production/vm
uname -a): Linux ubuntu-ws 4.13.0-17-generic #20-Ubuntu SMP Mon Nov 6 10:04:08 UTC 2017 x86_64 x86_64 x86_64 GNU/LinuxWhat happened:
Attempt to create cluster secret from file using a relative path via tilde to refer to home directory. I.E: ~/somefile
But this does not work, it generates a file not found error.
What you expected to happen:
I expect to be able to use tilde ~ in paths to files.
How to reproduce it (as minimally and precisely as possible):
# does not work, file not found.
kubectl create secret generic kubeconfig --from-file=~/somefile
# works fine
kubectl create secret generic kubeconfig --from-file=/home/
Anything else we need to know:
+1
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
/remove-lifecycle stale
@nikhita why was this marked at stale? Is it fixed?
I can work on this when I get a chance.
@nikhita why was this marked at stale?
We have a bot (@fejta-bot) which marks issues and PRs as "stale" if there has been no activity on it for 90 days. It is done to make sure that old issues are closed, if they are no longer relevant. If they are relevant, someone removes the stale label.
Is it fixed?
I haven't tested it but I don't think it is. If it were, I believe someone would have linked/referenced this issue on the PR.
I can work on this when I get a chance.
Please feel free to work on this. :)
This will work: kubectl create secret generic kubeconfig --from-file ~/somefile
Expansion of ~ paths to the home directory is done by the calling shell, and varies depending on whether the arg is quoted/unquoted, and is a flag or not. Bash chooses not to expand flag values containing ~. You can see this shell behavior in action with echo as well:
$ echo ~/test
/home/test
$ echo "~/test"
~/test
$ echo foo=~/test
foo=/home/test
$ echo "foo=~/test"
foo=~/test
$ echo --foo=~/test
--foo=~/test
$ echo "--foo=~/test"
--foo=~/test
I don't think it makes sense to add custom handling of every file-related flag value into every process to do this expansion.
/close
For those who run into this issue when trying to set a specific key:
kubectl create secret generic registry-secret \
--from-file=.dockerconfigjson=~/.docker/config.json \
--type=kubernetes.io/dockerconfigjson
A possible work around (albeit a little ugly) is:
kubectl create secret generic registry-secret \
--from-file=.dockerconfigjson=$(readlink -f ~/.docker/config.json) \
--type=kubernetes.io/dockerconfigjson
Most helpful comment
This will work:
kubectl create secret generic kubeconfig --from-file ~/somefileExpansion of ~ paths to the home directory is done by the calling shell, and varies depending on whether the arg is quoted/unquoted, and is a flag or not. Bash chooses not to expand flag values containing ~. You can see this shell behavior in action with echo as well:
I don't think it makes sense to add custom handling of every file-related flag value into every process to do this expansion.
/close