Hardcoded call to /usr/local/bin/kubectl fails
loeschzwerg opened this issue · 3 comments
I have kubectl
installed at /usr/bin/kubectl
via dnf
$ punq install -i punq.minikube.local
Do you really want to install punq to 'minikube' context? [Y/n]: y
Creating punq namespace ...
Created punq namespace. ✅
Creating punq RBAC ...
Created punq RBAC. ✅
Creating punq deployment ...
Created punq deployment. ✅
Determining cluster provider ...
Determined cluster provider: 'MINIKUBE'. ✅
Creating new punq-context secret ...
Created new punq-context secret. ✅
Creating punq service ...
Created punq service. ✅
Creating TRAEFIK punq ingress (punq.minikube.local) ...
Created TRAEFIK punq ingress (punq.minikube.local). ✅
Creating TRAEFIK middleware (punq.minikube.local) ...
Error: failed to execute command (/bin/bash -c /usr/local/bin/kubectl apply -f /tmp/traefik-middleware.yaml3688081572): exit status 127
/bin/bash: line 1: /usr/local/bin/kubectl: No such file or directory
A code review revealed there are several places where kubectl
is called on ¬Windows using the full path /usr/local/bin/kubectl
.
This is fine and desirable, but only when the fully qualified command is resolved, stored and checked.
Using a hardcoded call to /usr/local/bin/kubectl
will fail, when the caller doesn't have kubectl
installed at /usr/local/bin
.
This can be the case if it is installed via a package manager, like dnf
in my case, or when a custom location is chosen, e.g. when developing on kubectl.
There are four solutions and a local quick fix:
- Every call to
/usr/local/bin/kubectl
should be resolved via path, instead of being hard-coded. - On startup,
punq
checks whether kubectl is available using PATH but only on CLI calls which usekubectl
.kubectl
is defined once, and referred afterwards. - (Like 2. but with a singleton pattern which raises 4.)
- Instead of relying on an external CLI Tool like
kubectl
,punq
should talk directly with the API server, e.g. by using https://github.com/kubernetes/client-go/. This is already a dependency.
NOTE: 1, 2, 3 will create a mess, when the behaviour ofkubectl
is altered during execution, unlikely, but possible: e.g. kubectx
or kubens
changes.
Quick fix:
ln -s /usr/bin/kubectl /usr/local/bin/kubectl
At last, when one of the install
commands fails, I suggest punq
should do a clean up itself or reminds to do a clean install.
Very good points. Thx a lot for the detailed explaination :-)
Fix is iscoming in a few hours. Stay tuned.
Ok from a few hours to over a month. what a shame. sorry for that 😞
For simplicity reasons we will go with solution no1.
solution number 4 would be my first choice but we still need to use kubectl
because the describe functionallity is not easily available by using the kubernetes go-lang-package as a third party import.
I am gone close this now because it should be solved.