python: Not having a current context set causes

When initializing kubectl you typically do something like:

for cluster in clusters
do
  kubectl config set-cluster $cluster
  kubectl config set-credentials ...
  kubectl config set-context ...

That creates a valid config with multiple clusters, but with current-context set to "". If you try to load that config with config.load_kube_config() the library assumes "" is a context name and fails with the following:

  File "app/main.py", line 131, in get_versions
    config.load_kube_config()
  File "/usr/local/lib/python3.7/site-packages/kubernetes/config/kube_config.py", line 739, in load_kube_config
    persist_config=persist_config)
  File "/usr/local/lib/python3.7/site-packages/kubernetes/config/kube_config.py", line 707, in _get_kube_config_loader_for_yaml_file
    **kwargs)
  File "/usr/local/lib/python3.7/site-packages/kubernetes/config/kube_config.py", line 197, in __init__
    self.set_active_context(active_context)
  File "/usr/local/lib/python3.7/site-packages/kubernetes/config/kube_config.py", line 250, in set_active_context
    context_name)
  File "/usr/local/lib/python3.7/site-packages/kubernetes/config/kube_config.py", line 625, in get_with_name
    'Expected object with name %s in %s list' % (name, self.name))
kubernetes.config.config_exception.ConfigException: Invalid kube-config file. Expected object with name  in /kubeconfig/contexts list

Shouldn’t the library assume "" means the context is unset and avoid trying to look it up, or make the context argument to config.load_kube_config() mandatory?

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 27 (9 by maintainers)

Most upvoted comments

I don’t believe this was fixed. Just closed. It should be re-opened. This current behavior is a real pain for the use cases described in this thread

mwoodson on Jul 11, 2023

I am running into this issue just like @roycaihw is hitting. I am not able to list the context because the current-context is blank.

If current-context is blank then it should still be possible to get a listing of the contexts. kubectl supports this and doesn’t blow up.

vinayan3 on Jan 20, 2021

I can take that one. /assign

moshevayner on Nov 30, 2021

@MoShitrit

Well, I don’t see a point it silencing that exception when we know for sure that it’ll fail when it needs to call the API. What advantage do you see by having that kind of setup? Technically, every call to the API should fail if there’s no context, and I don’t see a situation in which we won’t have to call the API when using this client.

I’m actually trying to use the client to run commands on multiple clusters (which seems to be possible: https://github.com/kubernetes-client/python/blob/master/examples/multiple_clusters.py) so I’d have a defined context for every API requests but I don’t need a default one before I fetch the available contexts list.

/remove-lifecycle rotten

gdlx on Sep 28, 2021