Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Anything similar to Golang clientcmd ModifyConfig? #340

Open
ZedYeung opened this issue Sep 13, 2019 · 9 comments
Open

Anything similar to Golang clientcmd ModifyConfig? #340

ZedYeung opened this issue Sep 13, 2019 · 9 comments
Labels
lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.

Comments

@ZedYeung
Copy link

It looks like currently, we could only read the config file, is there any method like Golang clientcmd ModifyConfig so that we could modify the config file?

@brendandburns
Copy link
Contributor

Not currently. Can you describe your use case in more detail? Do you want to modify and then save to file a kubeconfig?

@ZedYeung
Copy link
Author

ZedYeung commented Sep 14, 2019 via email

@brendandburns
Copy link
Contributor

For future reference, code is here:
https://github.com/kubernetes/client-go/blob/master/tools/clientcmd/config.go#L158

Hrm. Why not just modify the config object in Javascript and then export to YAML?

That function seems super twisty and it's not exactly clear to me why its useful.

Can you describe your use case in more detail?

Thanks

@ZedYeung
Copy link
Author

That is exactly what it did. It is very true that function is super twisty with some rules. I just want to keep consistent with that official rule to modify the config file, in case some specific rule would be broken. But looks like that is not easy. What I do now is just modifying only one file in the order env KUBECONFIG and then ~/.kube/config. Hope that is good.

@brendandburns
Copy link
Contributor

That seems reasonable for now. I'll leave this issue open, but I don't expect we'll implement this in the near term.

@machine424
Copy link

machine424 commented Nov 25, 2019

If I really understand how tokens refreshing is implemented, new fetched tokens (at least for oidc) are not stored in ~/.kube/config, that means, if a refresh occurs, ~/.kube/config becomes obsolete. Also if other clients are to be run after, they will get old and unusable tokens from ~/.kube/config. The current refreshing process is only useful for a single long-running client ? I see that you've started working on configuration exporting (#372) Will tokens persistence be implemented soon ? Meanwhile, should it be done by the app using the client ? Thanks

@fejta-bot
Copy link

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-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Feb 24, 2020
@brendandburns
Copy link
Contributor

Token persistence is tricky, because it is potentially racy between multiple different clients running on the same machine.

I'd prefer that people handle it themselves in their application code rather than this library accidentally corrupting someone's kubeconfig.

@brendandburns
Copy link
Contributor

/lifecycle frozen

@k8s-ci-robot k8s-ci-robot added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Feb 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Projects
None yet
Development

No branches or pull requests

5 participants