Closed loeschzwerg closed 8 months ago
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.
I have
kubectl
installed at/usr/bin/kubectl
viadnf
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 havekubectl
installed at/usr/local/bin
. This can be the case if it is installed via a package manager, likednf
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:
/usr/local/bin/kubectl
should be resolved via path, instead of being hard-coded.punq
checks whether kubectl is available using PATH but only on CLI calls which usekubectl
.kubectl
is defined once, and referred afterwards.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 of
kubectl
is altered during execution, unlikely, but possible: e.g.kubectx
orkubens
changes.Quick fix:
At last, when one of the
install
commands fails, I suggestpunq
should do a clean up itself or reminds to do a clean install.