[jira] [Commented] (CAMEL-24662) camel-jbang: "camel kubernetes run --cluster-type X" is silently overridden by auto cluster detection

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

    [ https://issues.apache.org/jira/browse/CAMEL-24662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18115860#comment-18115860 ] 

Guillaume Nodet commented on CAMEL-24662:
-----------------------------------------

This issue is being investigated by a coding agent (on behalf of gnodet).

Confirmed in code: The detectCluster() method in KubernetesRun.java unconditionally overwrites the user-provided --cluster-type option. Since clusterType defaults to "Kubernetes", picocli cannot distinguish between the default and an explicit user value, so any auto-detected cluster silently wins.

Fix scope: Single PR -- guard detectCluster() to skip auto-detection when --cluster-type was explicitly provided by the user.

_Note: This comment was generated by an AI coding agent and requires manual verification._

> camel-jbang: "camel kubernetes run --cluster-type X" is silently overridden by auto cluster detection
> -----------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-24662
>                 URL: https://issues.apache.org/jira/browse/CAMEL-24662
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-jbang
>    Affects Versions: 4.22.0
>            Reporter: Federico Mariani
>            Assignee: Guillaume Nodet
>            Priority: Major
>
> {{KubernetesRun.detectCluster()}} unconditionally overwrites the {{clusterType}} field with the result of auto-detection, discarding whatever the user explicitly passed via {{--cluster-type}}, unless {{--disable-auto}} is also given:
> {code:java}
> // dsl/camel-jbang/camel-jbang-plugin-kubernetes/.../KubernetesRun.java:809
> private void detectCluster() {
>     if (!disableAuto) {
>         ...
>         ClusterType cluster = KubernetesHelper.discoverClusterType();
>         this.clusterType = cluster.name();   // clobbers the explicit --cluster-type value
>         if (ClusterType.MINIKUBE == cluster) {
>             this.imageBuilder = "docker";
>             this.imagePush = false;
>         } else if (ClusterType.OPENSHIFT == cluster) {
>             ...
>         }
>     }
> }
> {code}
> {{detectCluster()}} is called unconditionally from {{configureExport()}} before {{export.clusterType}} is read, so an explicit {{--cluster-type openshift}} (or any other value) only survives if auto-detection happens to agree with it. If the current kube context isn't reachable/detectable as OpenShift at CLI-invocation time (different network path than the actual deploy target, RBAC restricting the discovery call, CI without direct cluster access, etc.), the explicit flag is silently discarded and replaced with the auto-detected type - which also silently changes {{--image-builder}} (OpenShift forces {{docker}}, Minikube forces {{docker}} + disables push) and the jkube goal prefix ({{oc:}} vs {{k8s:}}) without any warning to the user.
> h3. Repro
> {noformat}
> camel kubernetes run --cluster-type openshift --output=yaml route.yaml application.properties
> {noformat}
> With a plain (non-OpenShift) kube context active, the generated project ends up using {{jkube.build.strategy=jib}} instead of {{docker}}, even though {{openshift}} was explicitly requested. Passing {{--disable-auto}} alongside {{--cluster-type openshift}} makes the explicit value stick (confirmed: {{jkube.build.strategy}} becomes {{docker}} and the deploy goal switches to {{oc:deploy}}).
> h3. Suggested fix
> Only run the auto-detection/override in {{detectCluster()}} when {{clusterType}} was not explicitly set by the user (e.g. track whether {{--cluster-type}} was passed, or seed the field with {{null}} and only assign when unset), instead of always overwriting it. At minimum, print a warning when the auto-detected type disagrees with an explicitly-provided {{--cluster-type}}.
> Found while investigating an unrelated report that {{camel.component.xslt-saxon.secureProcessing}} wasn't being honored on {{camel kubernetes run --cluster-type openshift}} deployments; that specific property-propagation behavior could not be reproduced (verified end-to-end across a plain Quarkus test, camel export, camel kubernetes run, a jib-built image, a live local Kubernetes deploy, and an OpenShift-style UBI/docker-built image - all correctly honored the property), so this ticket only covers the cluster-type override bug found along the way.
> _This issue was drafted by Claude Code on behalf of Federico Mariani_



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