davsclaus opened a new pull request, #29101: URL: https://github.com/apache/camel/pull/29101
Fixes [CAMEL-26241](https://issues.apache.org/jira/browse/CAMEL-26241). All three openshift producers now resolve the namespace the same way: the `CamelKubernetesNamespaceName` header, or else the `namespace` endpoint option. ### 1. openshift-deploymentconfigs: get, list and listByLabels ignored the namespace `doList`, `doListDeploymentConfigsByLabels` and `doGetDeploymentConfig` never called `inNamespace`, so they always used the namespace of the client. A deployment config in namespace `other` was not found by `getDeploymentConfig`. They now use `inNamespace(namespace)` when a namespace is set. Without one they still use the namespace of the client (unchanged). ### 2. openshift-builds and openshift-build-configs: list always listed all namespaces `listBuilds` and `listBuildConfigs` called `inAnyNamespace()` and ignored the header. They now use the namespace when one is set, like their ByLabels variants. Without one they still list all namespaces. ### 3. ByLabels without labels: NullPointerException `listBuildsByLabels`, `listBuildConfigsByLabels` and `listDeploymentConfigsByLabels` passed a missing labels header to `withLabels(null)` (NPE `"m" is null`). They now fail with an `IllegalArgumentException` ("... by labels requires specifying labels"), the same as the kubernetes-pods and kubernetes-services producers. ### 4. scaleDeploymentConfig failed when there was no status yet It returned `getStatus().getReplicas()` of the scaled config: an NPE when there is no status yet, and otherwise the current count, which may lag behind the requested one. It now returns the requested replicas (the `CamelKubernetesDeploymentReplicas` header). The existing `scaleDeploymentConfig` test asserted the status count of the mock (5 for a request of 1); it now expects 1. ### 5. The namespace option was not used by the producers The `namespace` option was read by the consumer only. The producers now fall back to it when the header is not set. This also applies to the operations that require a namespace (get build, get build config, create/update/delete/scale deployment config). The header wins over the option. ### Tests New `OpenshiftProducersNamespaceTest` (fabric8 mock server in CRUD mode, resources in namespaces `test` and `other`): 19 tests. 15 of them failed before the fix; the other 4 check the unchanged behaviour without a namespace. Module: 199 tests, 0 failures (6 skipped, as on main). ### Docs and generated files - The `@BodyTypes` descriptions of the three endpoints described the old behaviour ("listBuilds does not read the namespace header", "the replicas of its status"); updated and regenerated, with the catalog copies. - The three component pages say how the namespace is chosen. Fixed two operation names in them: `listDeploymentsConfigsByLabels` and (on the build configs page) `listBuildsByLabels`. - Upgrade guide 4.24: new section "camel-kubernetes - the openshift producers use the namespace header and option in every operation". ### Not changed - The kubernetes-* producers (custom-resources, scale of deployments and replication controllers, the namespace option) are CAMEL-26240, in a separate PR. The namespace lookup is a private method in each openshift producer here, so the two PRs do not touch the same files (except the upgrade guide). - `listBuilds`/`listBuildConfigs` without a namespace still list all namespaces, while `listDeploymentConfigs` uses the namespace of the client. I kept both defaults so that only routes that set a namespace see a change. _Claude Code on behalf of Claus Ibsen (davsclaus)_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
