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

load kubeconfig from custom environment variables #1097

Closed
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
12 changes: 11 additions & 1 deletion kube-client/src/config/file_config.rs
Original file line number Diff line number Diff line change
Expand Up @@ -361,7 +361,17 @@ impl Kubeconfig {
///
/// Panics if `KUBECONFIG` value contains the NUL character.
pub fn from_env() -> Result<Option<Self>, KubeconfigError> {
match std::env::var_os(KUBECONFIG) {
Self::from_custom_env(KUBECONFIG)
}

/// Create `Kubeconfig` from a given environment variable.
/// Supports list of files to be merged.
///
/// # Panics
///
/// Panics if the environment variable value contains the NUL character.
pub fn from_custom_env(env_name: &str) -> Result<Option<Self>, KubeconfigError> {
match std::env::var_os(env_name) {
Comment on lines -364 to +374
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As much as it feels like a rare use-case to have people use different evars, this way of exporting two sides of the functionality in from_env that you have here, is probably the best split.

Tried to think of a few other splits where ::from_env would parse the KUBECONFIG first, and maybe splits the paths, then maybe collects (and maybe even reads the files), before then calling a merger fn; but none of those options feel like they are actually giving us a useful split IO/non-IO split without making a very ugly interface.

That said, I'm kind of more positive on exporting the merge fn here than to have kube read a different non-standard evar as that feels very unexpected for kube to do (and something i expect to be an extremely rare use-case - unless I am missing something).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

100% understandable, it's a rare use-case indeed. Exporting merge would also work for me, so I created this other PR #1100

Copy link
Member

@clux clux Dec 7, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Appreciate it. Have merged that* pr and closed this PR. It's nicer to have fns that export documented parts of kubernetes algorithms be public.

Some(value) => {
let paths = std::env::split_paths(&value)
.filter(|p| !p.as_os_str().is_empty())
Expand Down