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

async signatures for kubeconfig loading is incorrect #1651

Open
clux opened this issue Nov 28, 2024 · 0 comments
Open

async signatures for kubeconfig loading is incorrect #1651

clux opened this issue Nov 28, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@clux
Copy link
Member

clux commented Nov 28, 2024

Current and expected behavior

As noted in #1645 and #1336

The kubeconfig file loading (which does need to do IO reading) is marked as async in the place it does not do any IO, and NOT marked as async in the place it does 🙃

Possible solution

Leave top-level fn as async, but swap around what is async;

pub async fn new_from_options(options: &KubeConfigOptions) -> Result<Self, KubeconfigError> {
let config = Kubeconfig::read()?;
let loader = Self::load(
config,
options.context.as_ref(),
options.cluster.as_ref(),
options.user.as_ref(),
)
.await?;

read() should be async and probably use tokio::fs (unless people have better ideas) and load() should be sync (it's a pure fn). This means the top level-fns are still async and it's a relatively minor breaking change to only low-level config loader fns.

For people who do wish to have a purely sync opener function (perhaps because people usually block at the start of an app's init), we could potentially add a secondary Config loader that's not async (by bypassing async read), but ideally would like this to be an addition rather than a breaking change (as proposed and rejected in #1650)

Affected crates

kube-client

@clux clux added the bug Something isn't working label Nov 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant