[jira] [Work started] (CAMEL-25454) camel-jbang - kubernetes run: --cluster-type=k3s with --output fails, and the Minikube defaults replace image options set by the user

["shashank (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-25454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on CAMEL-25454 started by shashank.
----------------------------------------
> camel-jbang - kubernetes run: --cluster-type=k3s with --output fails, and the Minikube defaults replace image options set by the user
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-25454
>                 URL: https://issues.apache.org/jira/browse/CAMEL-25454
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-jbang
>            Reporter: shashank
>            Assignee: shashank
>            Priority: Minor
>
> Follow-up to CAMEL-24662 ([PR #27216|https://github.com/apache/camel/pull/27216], merged as 7992aa5b45b4), from review points raised after the merge. {{camel kubernetes run}} now keeps an explicit {{--cluster-type}}, which exposes three problems:
> h3. 1. {{--cluster-type=k3s}} with {{--output}} fails
> {{KubernetesHelper.getKubernetesManifestPath()}} maps only KIND and MINIKUBE to {{kubernetes}}, so with K3S {{run --output=yaml}} looks for {{target/kubernetes/k3s.yml}}. {{KubernetesExport}} builds every cluster type but OpenShift with the {{kubernetes-maven-plugin}}, which writes {{kubernetes.yml}}:
> {noformat}
> java.io.FileNotFoundException: Unable to resolve Kubernetes manifest file type `yml` in folder: .../target/kubernetes
> {noformat}
> Before CAMEL-24662 the detected type replaced {{k3s}} unless {{--disable-auto}} was set, so the common case worked; with {{--disable-auto --cluster-type=k3s --output=yaml}} it already failed. All other {{ClusterType}} values resolve correctly (KUBERNETES, KIND, MINIKUBE: {{kubernetes.yml}}; OPENSHIFT: {{openshift.yml}}, written by the {{openshift-maven-plugin}}).
> h3. 2. Minikube defaults replace image options set by the user
> The Minikube defaults ({{imageBuilder=docker}}, {{imagePush=false}}) are applied unconditionally, so an explicit {{--image-builder=jib}} or {{--image-push=true}} is replaced, for an explicit and for a detected Minikube. CAMEL-21710, which added the automation, says: "if the user sets any parameter that is set by the automation, then the automation is disabled". The options had picocli default values, so an explicit value could not be told from the default.
> h3. 3. An explicit {{--cluster-type=minikube}} skips the docker-env check
> Detection only returns MINIKUBE when {{MINIKUBE_ACTIVE_DOCKERD}} and {{DOCKER_TLS_VERIFY}} are set, and prints the {{eval $(minikube docker-env)}} hint otherwise. With an explicit {{--cluster-type=minikube}} the image is built with Docker in the host daemon and not pushed, and nothing tells the user why the pod cannot pull it.
> Also: the test {{explicitMinikubeClusterTypeShouldApplyDefaults}} added by CAMEL-24662 passes without the fix (it sets the minikube env vars and the minikube node, so detection returns MINIKUBE anyway, and the test helper forces {{imagePush=false}}), and the docs say Kind is detected, while {{discoverClusterType()}} detects only OpenShift and Minikube.
> h3. Proposed fix
> * Map K3S to {{kubernetes}} in {{getKubernetesManifest()}} / {{getKubernetesManifestPath()}} (the knative path still passes {{service}}).
> * {{--image-builder}} and {{--image-push}} of {{kubernetes run}} have no picocli default; {{detectCluster()}} applies the Minikube defaults only to the options that are not set, then {{jib}} / {{true}}. {{--disable-auto}} still turns off detection and defaults.
> * With an explicit {{--cluster-type=minikube}}, the docker builder without push and no Minikube Docker environment, print the docker-env hint.
> * Make {{explicitMinikubeClusterTypeShouldApplyDefaults}} fail without the CAMEL-24662 fix (no minikube env or node, {{--image-push}} not forced); fix the Kind sentence in the docs; upgrade guide note for the {{--cluster-type}} and image option semantics.
> New tests: {{KubernetesHelperTest}} (manifest name per cluster type), {{KubernetesRunClusterTypeTest}} (cluster type and image defaults, without a Maven build, so it runs in CI, where the run, export and delete test classes of the module are disabled), and {{explicitK3sClusterTypeShouldOutputKubernetesManifest}} in {{KubernetesRunCustomTest}}. On main 5 of them fail (k3s.yml, FileNotFoundException, jib replaced by docker twice, no hint).
> Not in scope: {{--output=json}} fails for every cluster type, as JKube writes only {{kubernetes.yml}} by default and nothing asks it for JSON.
> Duplicate check (2026-10-06): JIRA text "cluster-type", "k3s", "minikube" (180 days), camel-jbang "image-builder": only CAMEL-24662, CAMEL-21710 and CAMEL-21392 (k3s support). GitHub pull requests "cluster-type", "k3s": #27216 only. No open PR touches the plugin's run command.
> _Filed with Claude Code on behalf of allthingssecurity._



--
This message was sent by Atlassian Jira
(v8.20.10#820010)