[
https://issues.apache.org/jira/browse/CAMEL-25454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18125669#comment-18125669
]
Claus Ibsen commented on CAMEL-25454:
-------------------------------------
Merged to main in https://github.com/apache/camel/pull/27591 (fixed in 4.23.0).
_Claude Code on behalf of davsclaus_
> 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
> Fix For: 4.23.0
>
>
> 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)
