gscloud path gets hard-coded into kubectl config

[dennisjac]

After setting up kubectl using gscloud kubectl now complains that it cannot find gscloud in /home/dennis/Downloads for some reason (I copied gscloud to /usr/local/bin):

$ kubectl get nodes
Unable to connect to the server: getting credentials: exec: fork/exec /home/dennis/Downloads/gscloud: no such file or directory

The problem seems to be that the path is hard-coded into the kubernetes config file as command: /home/dennis/Dowloads/gscloud. When I replace this with command: gscloud then kubectl finds the copy in /usr/local/bin and no longer throws an error.

[itakouna]

@dennisjac thanks for opening the issue. We will work on it ASAP.

[neur0manc]

As far as I can tell the current working directory is assumed to be the path to the gscloud executable. It should be relatively simple to determine the absolute path of the running executable, which should lead to a more robust solution:

package main

import (
    "fmt"
    "log"
    "os"
    "path/filepath"
)

func main() {
    dir, err := filepath.Abs(filepath.Dir(os.Args[0]))
    if err != nil {
        log.Fatal(err)
    }
    absPath := fmt.Sprintf("%s%s%s", dir, string(os.PathSeparator), os.Args[0])
    fmt.Println(absPath)
}

Which results in something like

~/source/personal/go % go build -o test test.go && ./test
/Users/Stephan/source/personal/go/./test

[itakouna]

@ls42 I think @dennisjac meant that gscloud path is hardcoded in ~/.kubeconfig/config. However, we provided subcommand kubernetes cluster save-kubeconfig that updates the ~/.kubeconfig/config with the right path. However, @dennisjac has moved gscloud after generating ~/.kubeconfig/config. Thus, he needs to update ~/.kubeconfig/config with the new gscloud path or he can use the subcommand kubernetes cluster save-kubeconfig.

part of kubeconfig file:

users:
- name: k8s-1-16-4-ss-test-admin
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      args:
      - --config
........
      command: /usr/local/bin/gscloud

[neur0manc]

meant that gscloud path is hardcoded in ~/.kubeconfig/config

Yes, that's true. But I think the issue is, that we assume the wrong directory as the path to the binary. @dennisjac seems to have the binary in /usr/local/bin, but we assume that it is in $PWD (and I don't think he moved it afterwards).

So in order to make a more robust solution, we should not assume that the binary is in the current working directory, but determine the absolute path to it and then write ~/.kube/config with the full path.

[bkircher]

So in order to make a more robust solution, we should not assume that the binary is in the current working directory, but determine the absolute path to it and then write ~/.kube/config with the full path.

Couldn't we just assume that the binary is installed in $PATH and not write the path to gscloud in kubeconfig at all?

[bkircher]

ping

[ajfriesen]

Just an idea:

How about storing the path of the gscloud binary in something like .cache/gscloud/path.env
Is it possible to store the path for gscloud in .cache/gscloud/path.env on every call?
Then kubectl could lookup this via an environment variable (I am not sure if this is possible).