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

Claus Ibsen commented on CAMEL-26241:
-------------------------------------

Update on PR https://github.com/apache/camel/pull/29101: aligned with 
CAMEL-26240 (PR #29102). The namespace lookup uses the same 
KubernetesHelper.extractNamespace, and scaleDeploymentConfig returns the 
replicas of the spec of the scaled deployment config (the requested count when 
the spec has none), like scaleDeployment there.

_Claude Code on behalf of Claus Ibsen (davsclaus)_

> camel-kubernetes - openshift-deploymentconfigs get and list ignore the 
> namespace header, and openshift listBuilds and listBuildConfigs always list 
> all namespaces
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-26241
>                 URL: https://issues.apache.org/jira/browse/CAMEL-26241
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-kubernetes
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>            Priority: Major
>             Fix For: 4.24.0
>
>
> Found while adding the catalog body types of the openshift components of 
> camel-kubernetes (CAMEL-24961, PR #28400). The kubernetes-* components are in 
> a separate issue.
> h4. 1. openshift-deploymentconfigs: get, list and listByLabels ignore the 
> namespace
> {{OpenshiftDeploymentConfigsProducer}} doList (main 2a465aa4814c, line 96), 
> doListDeploymentConfigsByLabels (line 105) and doGetDeploymentConfig (line 
> 117) do not read {{CamelKubernetesNamespaceName}}, while create, update, 
> delete and scale do. A deployment config created in namespace "other" is not 
> found by get. Checked on 4.24.0-SNAPSHOT with the fabric8 Kubernetes mock 
> server in CRUD mode.
> Proposed: use {{inNamespace(namespace)}} when the header (or the option) is 
> set, as the other operations do.
> h4. 2. openshift-builds and openshift-build-configs: list always lists all 
> namespaces
> {{OpenshiftBuildsProducer.doList}} (line 73) and 
> {{OpenshiftBuildConfigsProducer.doList}} (line 74) call {{inAnyNamespace()}} 
> and ignore the namespace header; their ByLabels variants honour it. Checked 
> on 4.24.0-SNAPSHOT with the fabric8 Kubernetes mock server in CRUD mode.
> Proposed: use the namespace when it is set, as the ByLabels variants do.
> h4. 3. ByLabels without labels: NullPointerException
> {{OpenshiftBuildConfigsProducer.doListBuildConfigsByLabels}} (lines 79-87) 
> passes a missing labels header to {{withLabels(null)}}, which fails with a 
> NullPointerException '"m" is null' (seen). 
> {{OpenshiftBuildsProducer.doListBuildByLabels}} (lines 78-86) and 
> {{OpenshiftDeploymentConfigsProducer.doListDeploymentConfigsByLabels}} (line 
> 105) have the same code (read in the code). Checked on 4.24.0-SNAPSHOT with 
> the fabric8 Kubernetes mock server in CRUD mode.
> Proposed: fail with a message that the labels header is required (or list all 
> when it is missing).
> h4. 4. openshift-deploymentconfigs scale fails when there is no status yet
> {{doScaleDeploymentConfig}} (line 204) returns {{getStatus().getReplicas()}}: 
> a NullPointerException when the returned config has no status yet, and 
> otherwise the current count, which may lag behind the requested one. Checked 
> on 4.24.0-SNAPSHOT with the fabric8 Kubernetes mock server in CRUD mode.
> Proposed: return the requested replicas (or {{getSpec().getReplicas()}}) and 
> guard against a null status.
> h4. 5. The namespace URI option is not used by the producers
> The three openshift producers read the namespace only from 
> {{CamelKubernetesNamespaceName}}; the {{namespace}} endpoint option is used 
> by the consumers only. Checked on 4.24.0-SNAPSHOT with the fabric8 Kubernetes 
> mock server in CRUD mode.
> Proposed: fall back to the {{namespace}} option when the header is not set.
> _Claude Code on behalf of davsclaus_



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to