Federico Mariani created CAMEL-24662:
----------------------------------------
Summary: 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
{{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)
