relative paths in kube config file are not interpreted correctly

[exarkun]

This was reported by a txkube user: https://github.com/LeastAuthority/txkube/issues/119. txkube uses pykube's config loader.

From the original report:

$ cat ~/.kube/config
apiVersion: v1
clusters:
- cluster:
    certificate-authority: dev-ca.crt
...

  File "/usr/local/lib/python2.7/dist-packages/pykube/config.py", line 142, in clusters
    BytesOrFile.maybe_set(c, "certificate-authority")
  File "/usr/local/lib/python2.7/dist-packages/pykube/config.py", line 225, in maybe_set
    d[file_key] = cls(filename=d[file_key])
  File "/usr/local/lib/python2.7/dist-packages/pykube/config.py", line 241, in __init__
    raise exceptions.PyKubeError("'{}' file does not exist".format(filename))
pykube.exceptions.PyKubeError: 'dev-ca.crt' file does not exist``` 

the ca file resides in ~/.kube/dev-ca.crt. The same problem reoccurs with users[].user.client-certificate and .client-key. Putting absolute paths into ~/.kube/config appears to avoid the issue.

[exarkun]

Anybody?

[brosner]

My apologies on the long response time.

I definitely want to see this supported. I am going to look up the expected behavior of kubectl here. Do you know if what you are proposing (relative paths are relative to the kube config) the behavior of kubectl?

[exarkun]

Thanks for the reply.

I'm not sure if this is the behavior of kubectl but the upstream bug report seems to imply it is. The value is taken from someone's existing ~/.kube/config and they were expecting it to work. I suspect that means they're successfully using it with kubectl but I don't know for sure.

[brosner]

I have confirmed that relative paths in kubeconfig should be resolved relative to the location of the file. I will get a fix up in the next couple of days.

[exarkun]

Any chance you've had time or will have time soon for this? Thanks. :)