wojciechgrazawskiahnl opened a new issue, #6730:
URL: https://github.com/apache/camel-k/issues/6730

   ## Environment
   - Camel K version: **`2.11.0-nightly`** (`pkg/util/defaults/defaults.go`)
   
   This is a question to confirm intended behavior before anything is changed. 
It concerns how the operator resolves its own image in the **v2.11.0-nightly** 
codebase.
   
   ### Summary
   
   The operator resolves its own image purely from the `CONTAINER_IMAGE` env 
var:
   
   - `pkg/cmd/operator/operator.go:273-274` — `getOperatorImage()` → 
`os.Getenv("CONTAINER_IMAGE")`
   - `pkg/cmd/operator/operator.go:159` — `platform.OperatorImage = 
getOperatorImage()`
   
   That value is populated **only** by a Kustomize `replacements` block that 
copies the Deployment's `image:` field into the env var:
   
   - `install/base/config/manager/operator-deployment.yaml:81-82` ships 
`CONTAINER_IMAGE: ""` (placeholder)
   - `install/base/config/manager/kustomization.yaml:32-40` copies 
`spec…containers[camel-k-operator].image` → `env[CONTAINER_IMAGE].value`
   
   The concern: the **Helm chart never sets `CONTAINER_IMAGE`** 
(`helm/camel-k/templates/operator-deployment.yaml` declares `WATCH_NAMESPACE`, 
`LOG_LEVEL`, `OPERATOR_NAME`, `REGISTRY_ADDRESS`, `POD_NAME`, `NAMESPACE`, 
`OPERATOR_ID` — no `CONTAINER_IMAGE`). Any install that doesn't run the 
Kustomize `replacements` step (Helm, or applying the base manifest directly) 
leaves `platform.OperatorImage == ""`.
   
   That value flows into the builder pod image with no fallback:
   
   - `pkg/controller/integration/build.go:128` and 
`pkg/controller/integrationkit/build.go:153` — `buildConfig.ToolImage = 
platform.OperatorImage`
   - `pkg/controller/build/build_pod.go:207` — `Image: 
build.BuilderConfiguration().ToolImage`
   
   So with the `pod` build strategy and an empty `CONTAINER_IMAGE`, the builder 
pod is created with an empty container image. (The `routine` strategy is 
unaffected since it builds in-process.)
   
   ### Questions
   
   1. Is relying solely on the injected `CONTAINER_IMAGE` env var intended, 
given the Helm chart does not set it in v2.11.0-nightly?
   2. Should the operator fall back to resolving its own image from its Pod 
spec (it already has `POD_NAME` / `NAMESPACE`) when `CONTAINER_IMAGE` is empty, 
and/or should the Helm chart set `CONTAINER_IMAGE`?
   
   ---
   _Claude Code on behalf of Wojciech Grażawski_


-- 
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]

Reply via email to