Fix(target-allocator): accept prometheus receiver with only target_allocator block

[sashetov]

Fix(target-allocator): accept prometheus receiver with only target_allocator block

Closes #2998

Summary

When an OpenTelemetryCollector CR has a prometheus receiver containing only a target_allocator: block (no config: / scrape_configs:), reconciliation fails with "no prometheusConfig available as part of the configuration". this is wrong - that shape is a legitimate "TA-only" mode where the target allocator supplies scrape configuration externally (typically from discovered PrometheusCR objects, or a configmap mounted on the TA, outside the operator's surface).

Note: a 2025-09-17 comment on the issue claimed this can't be reproduced, but I can't confirm that — the bug report shape (receiver with target_allocator: only, no config: at all) still triggers the error on main. unit-level repro below.

What Changed

• internal/manifests/targetallocator/adapters/config_to_prom_config.go - AddTAConfigToPromConfig now skips the scrape_configs strip when config: is absent instead of erroring; when config: is present the existing strip still runs. ValidateTargetAllocatorConfig returns nil when config: is absent (TA-only mode signal), instead of cascading the missing-config error from GetScrapeConfigsFromPromConfig.
• internal/manifests/targetallocator/adapters/config_to_prom_config_test.go - the previously-asserts-bug sub-case ("missing config property" → expects the old error) is removed from the negative test, and two positive sub-cases are added: "TA-only mode: no config block, only target_allocator set" and "TA-only mode: no config block, no target_allocator block". both assert no spurious config: key is inserted on the way out. TestValidateTargetAllocatorConfig gets its "receiver config empty and PrometheusCR disabled" row flipped from "expect error" to "expect nil", plus a new explicit "no config block but target_allocator set, PrometheusCR disabled" row.
• tests/e2e-targetallocator/targetallocator-no-promconfig/ - new chainsaw e2e: deploys an OpenTelemetryCollector with receivers: { prometheus: {} } and targetAllocator.enabled: true + prometheusCR.enabled: true, then asserts the collector and TA come up Ready and that the rendered collector configmap contains the operator-injected target_allocator block under prometheus: with no config: key.
• .chloggen/fix_target-allocator-only-config.yaml - bug_fix entry.

Reproduction

a throwaway test (not committed) calls both functions with the exact config from the bug report. at HEAD^ both fail with the bug's error; at HEAD both pass:

=== BEFORE (HEAD^): test against the initial source ===
=== RUN   TestRepro2998
    repro2998_test.go:32: 
        	Error Trace:	.../repro2998_test.go:32
        	Error:      	Received unexpected error:
        	            	no prometheusConfig available as part of the configuration
        	Test:       	TestRepro2998
        	Messages:   	AddTAConfigToPromConfig must accept TA-only config
    repro2998_test.go:35: 
        	Error Trace:	.../repro2998_test.go:35
        	Error:      	Received unexpected error:
        	            	no prometheusConfig available as part of the configuration
        	Test:       	TestRepro2998
        	Messages:   	ValidateTargetAllocatorConfig must accept TA-only config when PrometheusCR is disabled
--- FAIL: TestRepro2998 (0.00s)
FAIL
FAIL	github.com/open-telemetry/opentelemetry-operator/internal/manifests/targetallocator/adapters	0.011s

=== AFTER (HEAD): test against the PR source ===
=== RUN   TestRepro2998
--- PASS: TestRepro2998 (0.00s)
PASS
ok  	github.com/open-telemetry/opentelemetry-operator/internal/manifests/targetallocator/adapters	0.006s

The regression coverage that lands in this PR is in config_to_prom_config_test.go and the new chainsaw test under tests/e2e-targetallocator/targetallocator-no-promconfig/; the throwaway above is just to demonstrate the before-state in a single test file at the same commit.

Design

• skip rather than synthesise: the earlier draft of this fix synthesised an empty config: {} map so downstream code could keep writing into it. swiatekm pointed out the prometheus receiver doesn't require a config: block at all, so the synthesis is unnecessary. the current diff just guards the delete(prometheusCfg, "scrape_configs") behind the presence check — if there's no config:, there are no scrape_configs to strip and nothing else in AddTAConfigToPromConfig touches prometheusCfg. the rendered collector config stays minimal (just the operator-injected target_allocator block) and the chainsaw assert pins that shape.
• validator returns nil on missing config: not a permissive blanket-bypass — when config: is absent and TA is enabled (this whole code path runs only when TA is enabled), there is genuinely nothing to validate locally. the TA owns its scrape-config source.
• target_allocator.endpoint user-supplied value is still overwritten by the operator (unchanged). that's existing behavior; this PR doesn't change endpoint semantics, only the validation/strip path.

Tests

$ go test ./internal/manifests/targetallocator/... -count=1
ok  	github.com/open-telemetry/opentelemetry-operator/internal/manifests/targetallocator	0.055s
ok  	github.com/open-telemetry/opentelemetry-operator/internal/manifests/targetallocator/adapters	0.009s

$ go test ./internal/manifests/... -count=1 -short
ok  	github.com/open-telemetry/opentelemetry-operator/internal/manifests	0.035s
ok  	github.com/open-telemetry/opentelemetry-operator/internal/manifests/collector	0.064s
ok  	github.com/open-telemetry/opentelemetry-operator/internal/manifests/collector/adapters	0.006s
ok  	github.com/open-telemetry/opentelemetry-operator/internal/manifests/manifestutils	0.020s
ok  	github.com/open-telemetry/opentelemetry-operator/internal/manifests/opampbridge	0.027s
ok  	github.com/open-telemetry/opentelemetry-operator/internal/manifests/targetallocator	0.051s
ok  	github.com/open-telemetry/opentelemetry-operator/internal/manifests/targetallocator/adapters	0.010s

$ go test ./internal/webhook/... -count=1 -short
ok  	github.com/open-telemetry/opentelemetry-operator/internal/webhook	9.847s
ok  	github.com/open-telemetry/opentelemetry-operator/internal/webhook/podmutation	9.857s

$ gofmt -l internal/manifests/targetallocator/adapters/
(no output - clean)

$ go vet ./internal/manifests/targetallocator/... ./internal/webhook/...
(no output - clean)

make precommit not run end-to-end locally (envtest binaries download is slow on first run); the targeted go test runs above cover the same packages. the new chainsaw test runs under the operator's e2e-targetallocator suite in CI.

Notes

• no API changes, so make ensure-update-is-noop should be a no-op - verified by not editing anything under apis/.
• happy to split the ValidateTargetAllocatorConfig change out into a separate PR if maintainers prefer; both pieces are needed to fully resolve Target Allocator doesn't accept only target_allocator config in the collector config #2998 since both functions are called from the webhook (collector_webhook.go:330-337).

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: sashetov / name: Alex Vassilevski (5581200)

[swiatekm]

I don't think you need to set config: {}, prometheus receiver doesn't require that.

You should change this in some our e2e test configs - if they pass, it'll confirm that your change is valid.

Finally, you'll need to use an email address in your commit metadata that is linked to your GH account and sign the CLA with said account.

[github-actions]

E2E Test Results

 38 files  263 suites   2h 42m 15s ⏱️
111 tests 109 ✅ 1 💤 1 ❌
285 runs  279 ✅ 4 💤 2 ❌

Results for commit 5581200.

♻️ This comment has been updated with latest results.

[sashetov]

@swiatekm I dropped the config: {} and ec2 tests are passing

[swiatekm]

@swiatekm I dropped the config: {} and ec2 tests are passing

The TargetAllocator CRD tests are not passing, can you have a look?