kubernetes should adhere to the "XDG Base Directory Specification"

[ensonic]

/kind feature
/sig cli

What happened:
On linux several directories and files are created under ~/.kube/:

s -l ~/.kube/
total 32
drwxr-x---  3 ensonic users 4096 Jan 11  2017 cache
-rw-------  1 ensonic users 9052 Nov 27 10:41 config
drwxr-x---  3 ensonic users 4096 Nov 27 10:41 http-cache
drwxr-x--- 18 ensonic users 4096 Nov 13 13:06 schema

What you expected to happen:
Essentially the ~/.kube/cache should go to ~/.cache/kube/ and the configs to ~/.config/kube/.
For details see
https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

Anything else we need to know?:
The xdg setup eases maintenance (e.g. no need to backup cache dirs). This make it also easier to e.g. work with local tool (e.g. when running tools in docker, mount '.config' and be done istead of hunting each non standard config).

Environment:

• Kubernetes version (use kubectl version):
  Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.3", GitCommit:"f0efb3cb883751c5ffdbe6d515f3cb4fbe7b7acd", GitTreeState:"clean", BuildDate:"2017-11-08T18:39:33Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

• OS (e.g. from /etc/os-release):
  Debian GNU/Linux buster/sid

• Kernel (e.g. uname -a):
  4.9.0-4-amd64 Unit test coverage in Kubelet is lousy. (~30%) #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64 GNU/Linux

[razor-x]

Would love to see kubernetes make it to this list https://wiki.archlinux.org/index.php/XDG_Base_Directory_support

[fejta-bot]

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

[ensonic]

/remove-lifecycle stale

[fejta-bot]

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

[razor-x]

/remove-lifecycle stale

[fejta-bot]

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

[ensonic]

/remove-lifecycle stale

[fejta-bot]

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

[MazeChaZer]

/remove-lifecycle stale

[NelsonJeppesen]

/remove-lifecycle stale
🙏 don't go stale

[fejta-bot]

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

[remcohaszing]

/remove-lifecycle stale

[fejta-bot]

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

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[MazeChaZer]

/remove-lifecycle stale

[toastal]

This thread is embarrassing to read. This bot is useless. 65+ 👍‍ automatically means it's an issue people care about. Instead of you have a mess of bot and human-to-bot noise that makes this issue illegible. People get their time wasted by a bot email too to have to say, "yes, we're still here and interested in this bug--and never stopped being interested".

[tony-sol]

Totally agree with @toastal

[EvyBongers]

Any idea when this can be implemented?

[tony-sol]

@EvyBongers Looks like its slightly moving toward spec, according this PR #109479

[BenTheElder]

Please see kubernetes/enhancements#2111

I agree that this bot is annoying, it's possible to disable it
/lifecycle frozen

... but to be clear, something like this is not going to be implemented by filing a feature request here for many years now, a breaking change or new feature like this requires a KEP / enhancement proposal to be filed in the enhancements repo with the details reviewed agreed on how to handle it.

You can see in kubernetes/enhancements#2111 that so far the approach is rejected by SIG CLI due to the breaking changes.

[thepkc]

Necromancing this. This is still relevant. This can be made non breaking by having a list of folders to be checked, including the default one. This can even be made non breaking by implementing it through a variable check which is how most applications do it. If a config env file is set it'll look there. If it's not it uses legacy behaviour.

[BenTheElder]

This can be made non breaking by having a list of folders to be checked, including the default one.

please see the prior discussion linked, for more details on why that's still a problematic approach

roughly: there's a broad ecosystem and the configuration discovery is an API with multiple implementations. Things will break if we introduce skew in discovering the configuration files. The logic for this has been stable for many years and has implementations in many clients

you can always override KUBECONFIG to point to your XDG compliant directory and then all tools will read that.

[BenTheElder]

To ship a change of this scope someone will have to go through the enhancements process to outline an approved approach to ship it. The previously rejected enhancement is linked above with a lot of relevant discussion.

Unless someone writes up a more convincing enhancement and seeks approval from the kubectl maintainers, this is not happening.

The enhancements process allows us to ensure some rigor in how changes are introduced, feature gated, tested, and finally made GA.

If you're interested in making this happen, I would recommend talking to SIG api-machinery (for the client) and then SIG CLI before filing an enhancement.

[Volatus]

I like XDG but unfortunately I'll have to agree that it's likely way too much of a breaking change. Especially considering that setting KUBECONFIG will get you 90% of the way. Yes, you can't split the cache directory and what not but it's "enough". Way too many external tools rely on/make assumptions on where the kubeconfig is, and as long as they respect KUBECONFIG env var, they'll work fine. The return is simply not there in my opinion to justify a change like this.

[InSuperposition]

Is there a point of using semantic versioning (major versions), if breaking changes can't be introduced?

[BenTheElder]

Is there a point of using semantic versioning (major versions), if breaking changes can't be introduced?

Alpha/Beta features see breaking changes often. GA do not, but technically could under strict rules, and this would need to be communicated as well.

kubeconfig and the flags for it are course, GA.

For every user that wants this particular breaking change, there are many many more that want no breaking changes. Breaking changes to GA interfaces / APIs / ... (including k) are not taken lightly. The benefit needs to outweigh the costs to users and the ecosystem.

Again, if you'd like to propose a major change, the current mechanism to do so is a KEP: https://github.com/kubernetes/enhancements#is-my-thing-an-enhancement
Where the specifics can be worked through and reviewed in a structured manner, and with much more visibility than commenting on an eight year old issue in a repo with ~46k issues.

[BenTheElder]

cc @soltysh @eddiezane (SIG CLI doesn't appear to have an alias?) @kubernetes/sig-api-machinery-leads

[soltysh]

cc @soltysh @eddiezane (SIG CLI doesn't appear to have an alias?) @kubernetes/sig-api-machinery-leads

We've considered that long time ago, but the community dependence built around the current locations will not allow us to do that switch. Jordan linked this when we were discussing kuberc (https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/3104-introduce-kuberc/README.md) but decided not to. As you can see https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/2229-kubectl-xdg-base-dir/kep.yaml is marked as rejected, so I guess it's fair to close this issue as we won't be addressing it.

/close

[k8s-ci-robot]

@soltysh: Closing this issue.

In response to this:

cc @soltysh @eddiezane (SIG CLI doesn't appear to have an alias?) @kubernetes/sig-api-machinery-leads

We've considered that long time ago, but the community dependence built around the current locations will not allow us to do that switch. Jordan linked this when we were discussing kuberc (https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/3104-introduce-kuberc/README.md) but decided not to. As you can see https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/2229-kubectl-xdg-base-dir/kep.yaml is marked as rejected, so I guess it's fair to close this issue as we won't be addressing it.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.