timmy-mathew-ah opened a new pull request, #6543:
URL: https://github.com/apache/camel-k/pull/6543
## Summary
Parameterize all hardcoded Kubernetes resource names in Helm chart templates
using the existing `{{ include "camel-k.fullname" . }}` helper, enabling
installation of multiple Camel-K operators on the same cluster via Helm without
resource name collisions in same or different namespaces.
Fixes #6145, #6533
## Problem
The official Camel-K documentation describes an operator sharding pattern
when you set `global:true` during helm install where each operator has a unique
`OPERATOR_ID` and only reconciles resources annotated with the matching
`camel.apache.org/operator.id`. However, installing multiple operators via Helm
fails because **all resource names are hardcoded** to `camel-k-*` regardless of
the Helm release name or custom value.
Since `ClusterRoles` and `ClusterRoleBindings` are cluster-scoped (shared
across all namespaces), the second `helm install` immediately collides with the
first:
```bash
helm install camel-k-shard-1 camel-k/camel-k \
--namespace camel-k-shard-1 \
--create-namespace \
--set-string operator.global=true \
--set operator.operatorId=camel-k-shard-1
helm install camel-k-shard-2 camel-k/camel-k \
--namespace camel-k-shard-2 \
--create-namespace \
--set-string operator.global=true \
--set operator.operatorId=camel-k-shard-2
# Error: INSTALLATION FAILED: unable to continue with install:
# ClusterRole "camel-k-operator" in namespace "" exists and cannot be
# imported into the current release: invalid ownership metadata;
# annotation validation error: key "meta.helm.sh/release-name" must equal
# "camel-k-shard-2": current value is "camel-k-shard-1"
```
PR #6191 previously removed several unnecessary cluster-scoped resources but
the core problem remained, resource names were still hardcoded and not
parameterized by release name.
## Backward Compatibility
**Fully backward compatible**
The `camel-k.fullname` helper returns `camel-k` when the release name is
`camel-k` (the standard install). All resource names resolve to their original
hardcoded values and the rendered output is identical to the original chart for
both `global: true` and `global: false` modes.
```bash
# Standard install — output identical to before this fix
helm install camel-k camel-k/camel-k --namespace camel-k --create-namespace
```
## Supported Deployment Patterns
| Pattern | Before | After |
|---------|--------|-------|
| Single operator, `global: false` | ✅ | ✅ |
| Single operator, `global: true` | ✅ | ✅ |
| Multiple global operators, separate namespaces | ❌ ClusterRole collision |
✅ |
| Multiple global operators, same namespace | ❌ All resource collisions | ✅ |
| Multiple namespaced operators, same namespace | ❌ All resource collisions
| ✅ |
| Mixed global + namespaced operators | ❌ ClusterRole collision | ✅ |
---
## Usage Examples
### Single operator (unchanged behaviour)
```bash
helm install camel-k camel-k/camel-k \
--namespace camel-k \
--create-namespace
```
### Multiple global operators - separate namespaces
Each operator in its own namespace, watching the entire cluster, only
reconciling integrations annotated with its `operator.id`:
```bash
helm install camel-k-shard-1 camel-k/camel-k \
--namespace camel-k-shard-1 \
--create-namespace \
--set-string operator.global=true \
--set operator.operatorId=camel-k-shard-1
helm install camel-k-shard-2 camel-k/camel-k \
--namespace camel-k-shard-2 \
--create-namespace \
--set-string operator.global=true \
--set operator.operatorId=camel-k-shard-2
```
### Multiple global operators - same namespace
All operators managed in a single namespace. Enables IntegrationKit sharing
across shards (same runtime = reuse of already built kits):
```bash
helm install camel-k-shard-1 camel-k/camel-k \
--namespace camel-k-operators \
--create-namespace \
--set-string operator.global=true \
--set operator.operatorId=camel-k-shard-1
helm install camel-k-shard-2 camel-k/camel-k \
--namespace camel-k-operators \
--set-string operator.global=true \
--set operator.operatorId=camel-k-shard-2
```
## Known Limitation
The **builder ServiceAccount name** (`camel-k-builder`) is hardcoded in Go
code at `pkg/platform/defaults.go`:
```go
BuilderServiceAccount = "camel-k-builder"
```
Builder pods always use this SA name regardless of the Helm release name.
This means:
- Helm creates per-release builder SAs (e.g., `camel-k-shard-1-builder`) for
RBAC consistency
- The operator Go code creates and uses `camel-k-builder` at runtime for
actual builder pods
This is pre-existing behaviour, unchanged by this PR.
---
--
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]
