davsclaus opened a new pull request, #29919: URL: https://github.com/apache/camel/pull/29919
Items 1, 2 and 3 of [CAMEL-26934](https://issues.apache.org/jira/browse/CAMEL-26934). ## 1. `--kube-config` was ignored The JIRA found three places where `--kube-config` was not used: - `KubernetesDelete` took the static default client. - `KubernetesHelper.discoverClusterType` used the default client. - The JKube deploy (a Maven run) never got the kube config. While testing it I found a fourth cause, under every command: `KubernetesHelper.getKubernetesClient(String)` passed the file's content to `KubernetesClientBuilder.withConfig(String)`. That method unmarshals the text as a fabric8 `Config` bean (`masterUrl`, `namespace`, ...), not as a kube config file. So the clusters and contexts of a real kube config were ignored, and the client went to the default `kubernetes.default.svc`. In other words, `--kube-config` did not work for any command. Change: - `getKubernetesClient(String)` reads the content with `Config.fromKubeconfig`. - `KubernetesDelete` uses the client of the command, which honours `--kube-config`. - `discoverClusterType(KubernetesClient)` asks the given client. `delete` and the cluster detection of `run` pass theirs. - The Maven runs of `kubernetes run` get `KUBECONFIG` set to the given file, as the Kubernetes client of the JKube plugin reads it. ## 2. The client timeouts were set after the client was built `getKubernetesClient()` built the default client, then set the `kubernetes.connection.timeout` / `request.timeout` / `retry.backoffLimit` system properties, which the client had already read. Against an unreachable API server, `run --output yaml` took 40.7 s instead of about 2 s. The properties are now set first. A value the user sets still wins. Also, the "Failed to detect cluster ..." and minikube messages of the cluster detection go to stderr, as they ended up inside the YAML of `run --output yaml`. ## 3. `kubernetes logs` looped on a finished pod `isPodTerminated` checked the phase `Terminated`, which is not a pod phase. Pod phases are Pending, Running, Succeeded, Failed and Unknown. So the log of a finished pod was printed again every 2 seconds. A pod in Succeeded or Failed is now finished: its log is printed once, as `kubectl logs` does, and the command ends. A pod that finishes while its log is streamed also ends the command, without printing the log again. This also affects CronJob pods and `run --logs` / `--dev`. ## Tests - `KubernetesDeleteKubeConfigTest` (new): a deployment in a CRUD mock cluster. `delete --kube-config` points at it, while the default client points at an unreachable server. Before, the delete went to `kubernetes.default.svc` (UnknownHostException). Now it deletes the deployment in the namespace of the kube config. - `KubernetesHelperTest`: the default client has the 2 s timeouts. On main it has 10000 ms. - `KubernetesPodLogsTest`: the log of a Succeeded pod is read once, without retries. - camel-jbang-plugin-kubernetes: 159 tests pass. _Claude Code on behalf of davsclaus_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
