chore: update helm-charts for OTEL trace / metrics headers changes - #5941
Merged
akshaydeo merged 4 commits intoAug 10, 2026
Merged
Conversation
Contributor
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe Helm chart adds independent OTEL trace control, trace and metrics header overrides, and conditional validation for profile-based and top-level configurations. Values examples and release notes document the new options. ChangesOTEL configuration
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
This was referenced Aug 7, 2026
Contributor
Author
This was referenced Aug 7, 2026
roroghost17
marked this pull request as ready for review
August 7, 2026 08:20
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@helm-charts/bifrost/values.schema.json`:
- Line 5046: Update the metrics validation condition in the profile schema
around the required metrics_endpoint and protocol rule so it is skipped when the
profile’s enabled property is false, matching the existing trace validation
behavior. Ensure stale metrics_enabled values cannot require metrics fields for
disabled profiles.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 92752653-8904-4cdc-b04c-00bb55383208
📒 Files selected for processing (4)
helm-charts/bifrost/README.mdhelm-charts/bifrost/templates/_helpers.tplhelm-charts/bifrost/values.schema.jsonhelm-charts/bifrost/values.yaml
roroghost17
force-pushed
the
08-07-feat_add_separate_headers_support_for_traces_and_metrics_in_otel_collector
branch
from
August 7, 2026 09:49
e48d172 to
a6883e2
Compare
roroghost17
force-pushed
the
08-07-chore_update_helm-charts_for_otel_trace___metrics_headers_changes
branch
from
August 7, 2026 09:49
e718291 to
8bf75e3
Compare
Contributor
Merge activity
|
akshaydeo
changed the base branch from
08-07-feat_add_separate_headers_support_for_traces_and_metrics_in_otel_collector
to
graphite-base/5941
August 10, 2026 15:18
akshaydeo
dismissed
coderabbitai[bot]’s stale review
August 10, 2026 15:20
The base branch was changed.
akshaydeo
deleted the
08-07-chore_update_helm-charts_for_otel_trace___metrics_headers_changes
branch
August 10, 2026 15:20
akshaydeo
pushed a commit
that referenced
this pull request
Aug 10, 2026
…5941) Adds `traces_enabled`, `trace_headers`, and `metrics_headers` fields to the OTEL plugin configuration (both single-profile and multi-profile shapes), enabling metrics-only OTEL profiles and per-signal header overrides. - Added `traces_enabled` boolean to OTEL config. When set to `false`, trace export is skipped and `collector_url` / `trace_type` are no longer required, allowing a metrics-only profile to be configured without a trace collector. - Added `trace_headers` and `metrics_headers` maps to OTEL config. The existing `headers` field continues to apply to both endpoints; `trace_headers` and `metrics_headers` are overlaid on top per-signal, with the more specific key winning on conflict. This supports cases where a collector requires a signal-specific header (e.g. a Databricks table name on the metrics endpoint only). - Updated validation logic in `_helpers.tpl` so that `collector_url` and `trace_type` are only required when `traces_enabled` is `true`, and `protocol` is only required when at least one of traces or metrics is enabled. - Updated `values.schema.json` conditional validation (`allOf`/`if`/`then`) to reflect the same rules: `collector_url`, `trace_type`, and `protocol` are gated on both `enabled` and `traces_enabled` not being `false`; `metrics_endpoint` and `protocol` are required together when `metrics_enabled` is `true`. - Updated `values.yaml` comments and `README.md` changelog to document the new fields. - [ ] Bug fix - [x] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI - [ ] Core (Go) - [ ] Transports (HTTP) - [ ] Providers/Integrations - [x] Plugins - [ ] UI (React) - [ ] Docs Deploy the Helm chart with a metrics-only OTEL profile and verify that no trace collector URL is required: ```yaml bifrost: plugins: otel: enabled: true config: traces_enabled: false metrics_enabled: true metrics_endpoint: "http://otel-collector:4318/v1/metrics" protocol: "http" metrics_headers: x-databricks-table: "my_table" ``` ```sh helm template . -f values.yaml | grep -A 30 "otel" helm lint . ``` Verify that omitting `collector_url` with `traces_enabled: false` passes linting, and that omitting it with `traces_enabled: true` (default) still fails with the appropriate error message. N/A - [ ] Yes - [x] No N/A `trace_headers` and `metrics_headers` support the `env.VAR_NAME` prefix for injecting secrets from environment variables, consistent with the existing `headers` field. No new secret handling mechanisms are introduced. - [ ] I read `docs/contributing/README.md` and followed the guidelines - [ ] I added/updated tests where appropriate - [x] I updated documentation where needed - [ ] I verified builds succeed (Go and UI) - [ ] I verified the CI pipeline passes locally if applicable
akshaydeo
pushed a commit
that referenced
this pull request
Aug 13, 2026
…5941) Adds `traces_enabled`, `trace_headers`, and `metrics_headers` fields to the OTEL plugin configuration (both single-profile and multi-profile shapes), enabling metrics-only OTEL profiles and per-signal header overrides. - Added `traces_enabled` boolean to OTEL config. When set to `false`, trace export is skipped and `collector_url` / `trace_type` are no longer required, allowing a metrics-only profile to be configured without a trace collector. - Added `trace_headers` and `metrics_headers` maps to OTEL config. The existing `headers` field continues to apply to both endpoints; `trace_headers` and `metrics_headers` are overlaid on top per-signal, with the more specific key winning on conflict. This supports cases where a collector requires a signal-specific header (e.g. a Databricks table name on the metrics endpoint only). - Updated validation logic in `_helpers.tpl` so that `collector_url` and `trace_type` are only required when `traces_enabled` is `true`, and `protocol` is only required when at least one of traces or metrics is enabled. - Updated `values.schema.json` conditional validation (`allOf`/`if`/`then`) to reflect the same rules: `collector_url`, `trace_type`, and `protocol` are gated on both `enabled` and `traces_enabled` not being `false`; `metrics_endpoint` and `protocol` are required together when `metrics_enabled` is `true`. - Updated `values.yaml` comments and `README.md` changelog to document the new fields. - [ ] Bug fix - [x] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI - [ ] Core (Go) - [ ] Transports (HTTP) - [ ] Providers/Integrations - [x] Plugins - [ ] UI (React) - [ ] Docs Deploy the Helm chart with a metrics-only OTEL profile and verify that no trace collector URL is required: ```yaml bifrost: plugins: otel: enabled: true config: traces_enabled: false metrics_enabled: true metrics_endpoint: "http://otel-collector:4318/v1/metrics" protocol: "http" metrics_headers: x-databricks-table: "my_table" ``` ```sh helm template . -f values.yaml | grep -A 30 "otel" helm lint . ``` Verify that omitting `collector_url` with `traces_enabled: false` passes linting, and that omitting it with `traces_enabled: true` (default) still fails with the appropriate error message. N/A - [ ] Yes - [x] No N/A `trace_headers` and `metrics_headers` support the `env.VAR_NAME` prefix for injecting secrets from environment variables, consistent with the existing `headers` field. No new secret handling mechanisms are introduced. - [ ] I read `docs/contributing/README.md` and followed the guidelines - [ ] I added/updated tests where appropriate - [x] I updated documentation where needed - [ ] I verified builds succeed (Go and UI) - [ ] I verified the CI pipeline passes locally if applicable
akshaydeo
pushed a commit
that referenced
this pull request
Aug 13, 2026
…5941) Adds `traces_enabled`, `trace_headers`, and `metrics_headers` fields to the OTEL plugin configuration (both single-profile and multi-profile shapes), enabling metrics-only OTEL profiles and per-signal header overrides. - Added `traces_enabled` boolean to OTEL config. When set to `false`, trace export is skipped and `collector_url` / `trace_type` are no longer required, allowing a metrics-only profile to be configured without a trace collector. - Added `trace_headers` and `metrics_headers` maps to OTEL config. The existing `headers` field continues to apply to both endpoints; `trace_headers` and `metrics_headers` are overlaid on top per-signal, with the more specific key winning on conflict. This supports cases where a collector requires a signal-specific header (e.g. a Databricks table name on the metrics endpoint only). - Updated validation logic in `_helpers.tpl` so that `collector_url` and `trace_type` are only required when `traces_enabled` is `true`, and `protocol` is only required when at least one of traces or metrics is enabled. - Updated `values.schema.json` conditional validation (`allOf`/`if`/`then`) to reflect the same rules: `collector_url`, `trace_type`, and `protocol` are gated on both `enabled` and `traces_enabled` not being `false`; `metrics_endpoint` and `protocol` are required together when `metrics_enabled` is `true`. - Updated `values.yaml` comments and `README.md` changelog to document the new fields. - [ ] Bug fix - [x] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI - [ ] Core (Go) - [ ] Transports (HTTP) - [ ] Providers/Integrations - [x] Plugins - [ ] UI (React) - [ ] Docs Deploy the Helm chart with a metrics-only OTEL profile and verify that no trace collector URL is required: ```yaml bifrost: plugins: otel: enabled: true config: traces_enabled: false metrics_enabled: true metrics_endpoint: "http://otel-collector:4318/v1/metrics" protocol: "http" metrics_headers: x-databricks-table: "my_table" ``` ```sh helm template . -f values.yaml | grep -A 30 "otel" helm lint . ``` Verify that omitting `collector_url` with `traces_enabled: false` passes linting, and that omitting it with `traces_enabled: true` (default) still fails with the appropriate error message. N/A - [ ] Yes - [x] No N/A `trace_headers` and `metrics_headers` support the `env.VAR_NAME` prefix for injecting secrets from environment variables, consistent with the existing `headers` field. No new secret handling mechanisms are introduced. - [ ] I read `docs/contributing/README.md` and followed the guidelines - [ ] I added/updated tests where appropriate - [x] I updated documentation where needed - [ ] I verified builds succeed (Go and UI) - [ ] I verified the CI pipeline passes locally if applicable
akshaydeo
pushed a commit
that referenced
this pull request
Aug 14, 2026
…5941) Adds `traces_enabled`, `trace_headers`, and `metrics_headers` fields to the OTEL plugin configuration (both single-profile and multi-profile shapes), enabling metrics-only OTEL profiles and per-signal header overrides. - Added `traces_enabled` boolean to OTEL config. When set to `false`, trace export is skipped and `collector_url` / `trace_type` are no longer required, allowing a metrics-only profile to be configured without a trace collector. - Added `trace_headers` and `metrics_headers` maps to OTEL config. The existing `headers` field continues to apply to both endpoints; `trace_headers` and `metrics_headers` are overlaid on top per-signal, with the more specific key winning on conflict. This supports cases where a collector requires a signal-specific header (e.g. a Databricks table name on the metrics endpoint only). - Updated validation logic in `_helpers.tpl` so that `collector_url` and `trace_type` are only required when `traces_enabled` is `true`, and `protocol` is only required when at least one of traces or metrics is enabled. - Updated `values.schema.json` conditional validation (`allOf`/`if`/`then`) to reflect the same rules: `collector_url`, `trace_type`, and `protocol` are gated on both `enabled` and `traces_enabled` not being `false`; `metrics_endpoint` and `protocol` are required together when `metrics_enabled` is `true`. - Updated `values.yaml` comments and `README.md` changelog to document the new fields. - [ ] Bug fix - [x] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI - [ ] Core (Go) - [ ] Transports (HTTP) - [ ] Providers/Integrations - [x] Plugins - [ ] UI (React) - [ ] Docs Deploy the Helm chart with a metrics-only OTEL profile and verify that no trace collector URL is required: ```yaml bifrost: plugins: otel: enabled: true config: traces_enabled: false metrics_enabled: true metrics_endpoint: "http://otel-collector:4318/v1/metrics" protocol: "http" metrics_headers: x-databricks-table: "my_table" ``` ```sh helm template . -f values.yaml | grep -A 30 "otel" helm lint . ``` Verify that omitting `collector_url` with `traces_enabled: false` passes linting, and that omitting it with `traces_enabled: true` (default) still fails with the appropriate error message. N/A - [ ] Yes - [x] No N/A `trace_headers` and `metrics_headers` support the `env.VAR_NAME` prefix for injecting secrets from environment variables, consistent with the existing `headers` field. No new secret handling mechanisms are introduced. - [ ] I read `docs/contributing/README.md` and followed the guidelines - [ ] I added/updated tests where appropriate - [x] I updated documentation where needed - [ ] I verified builds succeed (Go and UI) - [ ] I verified the CI pipeline passes locally if applicable
akshaydeo
pushed a commit
that referenced
this pull request
Aug 19, 2026
…5941) Adds `traces_enabled`, `trace_headers`, and `metrics_headers` fields to the OTEL plugin configuration (both single-profile and multi-profile shapes), enabling metrics-only OTEL profiles and per-signal header overrides. - Added `traces_enabled` boolean to OTEL config. When set to `false`, trace export is skipped and `collector_url` / `trace_type` are no longer required, allowing a metrics-only profile to be configured without a trace collector. - Added `trace_headers` and `metrics_headers` maps to OTEL config. The existing `headers` field continues to apply to both endpoints; `trace_headers` and `metrics_headers` are overlaid on top per-signal, with the more specific key winning on conflict. This supports cases where a collector requires a signal-specific header (e.g. a Databricks table name on the metrics endpoint only). - Updated validation logic in `_helpers.tpl` so that `collector_url` and `trace_type` are only required when `traces_enabled` is `true`, and `protocol` is only required when at least one of traces or metrics is enabled. - Updated `values.schema.json` conditional validation (`allOf`/`if`/`then`) to reflect the same rules: `collector_url`, `trace_type`, and `protocol` are gated on both `enabled` and `traces_enabled` not being `false`; `metrics_endpoint` and `protocol` are required together when `metrics_enabled` is `true`. - Updated `values.yaml` comments and `README.md` changelog to document the new fields. - [ ] Bug fix - [x] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI - [ ] Core (Go) - [ ] Transports (HTTP) - [ ] Providers/Integrations - [x] Plugins - [ ] UI (React) - [ ] Docs Deploy the Helm chart with a metrics-only OTEL profile and verify that no trace collector URL is required: ```yaml bifrost: plugins: otel: enabled: true config: traces_enabled: false metrics_enabled: true metrics_endpoint: "http://otel-collector:4318/v1/metrics" protocol: "http" metrics_headers: x-databricks-table: "my_table" ``` ```sh helm template . -f values.yaml | grep -A 30 "otel" helm lint . ``` Verify that omitting `collector_url` with `traces_enabled: false` passes linting, and that omitting it with `traces_enabled: true` (default) still fails with the appropriate error message. N/A - [ ] Yes - [x] No N/A `trace_headers` and `metrics_headers` support the `env.VAR_NAME` prefix for injecting secrets from environment variables, consistent with the existing `headers` field. No new secret handling mechanisms are introduced. - [ ] I read `docs/contributing/README.md` and followed the guidelines - [ ] I added/updated tests where appropriate - [x] I updated documentation where needed - [ ] I verified builds succeed (Go and UI) - [ ] I verified the CI pipeline passes locally if applicable
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Summary
Adds
traces_enabled,trace_headers, andmetrics_headersfields to the OTEL plugin configuration (both single-profile and multi-profile shapes), enabling metrics-only OTEL profiles and per-signal header overrides.Changes
traces_enabledboolean to OTEL config. When set tofalse, trace export is skipped andcollector_url/trace_typeare no longer required, allowing a metrics-only profile to be configured without a trace collector.trace_headersandmetrics_headersmaps to OTEL config. The existingheadersfield continues to apply to both endpoints;trace_headersandmetrics_headersare overlaid on top per-signal, with the more specific key winning on conflict. This supports cases where a collector requires a signal-specific header (e.g. a Databricks table name on the metrics endpoint only)._helpers.tplso thatcollector_urlandtrace_typeare only required whentraces_enabledistrue, andprotocolis only required when at least one of traces or metrics is enabled.values.schema.jsonconditional validation (allOf/if/then) to reflect the same rules:collector_url,trace_type, andprotocolare gated on bothenabledandtraces_enablednot beingfalse;metrics_endpointandprotocolare required together whenmetrics_enabledistrue.values.yamlcomments andREADME.mdchangelog to document the new fields.Type of change
Affected areas
How to test
Deploy the Helm chart with a metrics-only OTEL profile and verify that no trace collector URL is required:
Verify that omitting
collector_urlwithtraces_enabled: falsepasses linting, and that omitting it withtraces_enabled: true(default) still fails with the appropriate error message.Screenshots/Recordings
N/A
Breaking changes
Related issues
N/A
Security considerations
trace_headersandmetrics_headerssupport theenv.VAR_NAMEprefix for injecting secrets from environment variables, consistent with the existingheadersfield. No new secret handling mechanisms are introduced.Checklist
docs/contributing/README.mdand followed the guidelines