feat: Tulip LTS May 2026 — upgrade to v0.150.0#35
Merged
Conversation
- Bump all components from v0.145.0 to v0.150.0 - Remove deprecated batchprocessor, replace with exporter-level batching - Add memorylimiterprocessor for OOM protection - Update default config with sending_queue, batch, and retry_on_failure - Add LTS upgrade plan documentation - Fix bash 3.2 compatibility in test script
📝 WalkthroughWalkthroughBumps Tulip to v0.151.0, removes the ChangesTulip LTS / Distribution Upgrade
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
docs/tulip-lts-may2026-upgrade-plan.md (1)
87-93: Consider addingmemory_limiterto the "After" example for consistency.The "After" example shows
processors: [], but the actualconfig.yamlimplementation usesprocessors: [memory_limiter]. Since the documentation later states that "memory_limiter should be the first processor in every pipeline" (line 127), including it here would provide a more complete migration example.📝 Suggested update
service: pipelines: traces: receivers: [otlp] - processors: [] + processors: [memory_limiter] exporters: [otlp]🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/tulip-lts-may2026-upgrade-plan.md` around lines 87 - 93, Update the "After" example so the traces pipeline lists the memory_limiter processor (change processors: [] to processors: [memory_limiter]) to match the actual config and the guidance that "memory_limiter should be the first processor in every pipeline"; locate the example under service -> pipelines -> traces in the doc and ensure memory_limiter is included in that processors array.test/generate-trace.sh (1)
15-15: Quote the variable to prevent word splitting and globbing.The
${distribution}variable should be quoted. If the distribution name contains spaces or glob characters, this could cause unexpected behavior or file path issues.🛡️ Proposed fix
-tracegen -otlp-endpoint localhost:4317 -otlp-insecure -service e2e-test >> ./test/logs/tracegen-${distribution}.log 2>&1 +tracegen -otlp-endpoint localhost:4317 -otlp-insecure -service e2e-test >> "./test/logs/tracegen-${distribution}.log" 2>&1🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/generate-trace.sh` at line 15, The redirection filename uses an unquoted shell variable which can cause word splitting/globbing for names with spaces or wildcards; update the trace generation command (the tracegen invocation that writes to ./test/logs/tracegen-${distribution}.log) to quote the ${distribution} variable in the output filename so the shell treats it as a single word and prevents glob expansion.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@distributions/tulip/config.yaml`:
- Around line 20-30: The config is missing the file_storage extension and the
sending_queue.storage references so queues remain in-memory; add an extensions
block defining file_storage (e.g., file_storage.directory:
/var/lib/otelcol/queue), add file_storage to service.extensions, and update both
exporter blocks (exporters.otlp.sending_queue and
exporters.otlphttp.sending_queue) to include storage: file_storage so durable
queuing is enabled; ensure existing sending_queue, batch, and retry_on_failure
settings are preserved.
---
Nitpick comments:
In `@docs/tulip-lts-may2026-upgrade-plan.md`:
- Around line 87-93: Update the "After" example so the traces pipeline lists the
memory_limiter processor (change processors: [] to processors: [memory_limiter])
to match the actual config and the guidance that "memory_limiter should be the
first processor in every pipeline"; locate the example under service ->
pipelines -> traces in the doc and ensure memory_limiter is included in that
processors array.
In `@test/generate-trace.sh`:
- Line 15: The redirection filename uses an unquoted shell variable which can
cause word splitting/globbing for names with spaces or wildcards; update the
trace generation command (the tracegen invocation that writes to
./test/logs/tracegen-${distribution}.log) to quote the ${distribution} variable
in the output filename so the shell treats it as a single word and prevents glob
expansion.
🪄 Autofix (Beta)
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: Repository: ollygarden/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 859ce0d5-2e2b-4643-b1a0-9907a2646e61
📒 Files selected for processing (4)
distributions/tulip/config.yamldistributions/tulip/manifest.yamldocs/tulip-lts-may2026-upgrade-plan.mdtest/generate-trace.sh
Signed-off-by: perebaj <perebaj@gmail.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 `@docs/tulip-lts-may2026-upgrade-plan.md`:
- Around line 87-93: Update the "After" pipeline example so
service.pipelines.traces.processors is not an empty array but includes
memory_limiter as the first processor to align with the document guidance;
specifically, ensure the pipelines.traces processors list begins with the
memory_limiter processor (refer to the memory_limiter processor name and the
service.pipelines.traces.processors array in the example) so the example matches
the stated production-safe default.
- Around line 40-45: Update the paragraph about exporter-level batching to
clarify that durable persistence and disk recovery are not automatic: explicitly
state that the sending_queue only persists to disk and recovers after a
Collector restart when the exporter's storage configuration is enabled and
pointed to persistent storage (i.e., the exporter-level "sending_queue" must be
configured with the appropriate "storage" settings); adjust the phrases "durably
enqueued in the persistent sending queue", "written to disk", and "recovered
after a Collector restart" to indicate they apply only when storage is
configured, and suggest operators verify exporter "sending_queue" + "storage"
settings when choosing this approach.
🪄 Autofix (Beta)
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: Repository: ollygarden/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 200de0f3-5435-400f-bf7a-ae5e1cb1ce78
📒 Files selected for processing (1)
docs/tulip-lts-may2026-upgrade-plan.md
Contributor
Author
|
we do not have the intention to support processor/memory_limiter because it will be replaced by this component here We will also remove the healthcheck extension v1 because v2 and v1 share code between them using a feature flag. Reference. In this case, we will indirectly support v2, which is not our objective for an LTS version of Tulip. New components that we gonna support
|
Signed-off-by: perebaj <perebaj@gmail.com>
Signed-off-by: perebaj <perebaj@gmail.com>
Signed-off-by: perebaj <perebaj@gmail.com>
Signed-off-by: perebaj <perebaj@gmail.com>
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 `@docs/tulip-lts-may2026-upgrade-plan.md`:
- Line 134: The heading "## Final LTS Component Manifest (28 components)" is
incorrect; update it to reflect the actual count of 27 components by changing
the text to "## Final LTS Component Manifest (27 components)"; verify the change
by cross-checking the tables that sum to 27 (7+4+5+7+1+3) and ensure no other
headings or references still say 28.
🪄 Autofix (Beta)
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: Repository: ollygarden/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 17daef7c-35b6-437f-8d2a-75789b98c3d5
📒 Files selected for processing (4)
README.mddistributions/tulip/config.yamldistributions/tulip/manifest.yamldocs/tulip-lts-may2026-upgrade-plan.md
Signed-off-by: perebaj <perebaj@gmail.com>
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
test/start-otelcol.sh (1)
39-44:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winUpdate retry/failure log text to match the new readiness strategy.
Line 39 and Line 43 still refer to “Server unavailable/up,” but this loop now waits for a log readiness marker. This can mislead CI debugging.
Suggested wording tweak
- echo "Server still unavailable" >> ./test/logs/test-${distribution}.log + echo "Collector not ready yet (waiting for startup log marker)" >> ./test/logs/test-${distribution}.log ... - echo "❌ FAIL. Server wasn't up after about 5s." + echo "❌ FAIL. Collector did not report readiness after about 5s."🤖 Prompt for 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. In `@test/start-otelcol.sh` around lines 39 - 44, Update the retry/failure messages to reflect the new readiness-by-log-marker strategy: replace the "Server still unavailable" append into ./test/logs/test-${distribution}.log with a message like "Readiness marker not found" (or similar), and change the failure echo that currently says "❌ FAIL. Server wasn't up after about 5s." to "❌ FAIL. Readiness marker not found after about 5s." so the output and log use the readiness-marker terminology; modify the lines that perform the echo to ensure they reference retries, max_retries and the distribution variable unchanged.
♻️ Duplicate comments (1)
docs/tulip-lts-may2026-upgrade-plan.md (1)
40-45:⚠️ Potential issue | 🟠 Major | ⚡ Quick winClarify that
sending_queuedurability requires explicit storage wiring.Line 42 and Line 44 describe durability/restart recovery as inherent, but the "After" example (Line 71 onward) does not configure exporter
sending_queue.storageorservice.extensionsstorage extension. As written, this can be read as crash-safe by default.Suggested doc fix
-**Replacement:** Exporter-level batching via `sending_queue` + `batch` configuration on each exporter. This is the officially recommended path and provides stronger delivery guarantees because: +**Replacement:** Exporter-level batching via `sending_queue` + `batch` configuration on each exporter. This is the officially recommended path and provides stronger delivery guarantees (with persistent queue storage configured) because: -- Data is durably enqueued in the exporter's persistent sending queue before acknowledgment +- Data is enqueued in the exporter's sending queue before send attempts - Batching and queueing are consolidated within the exporter -- Data can be written to disk and recovered after a Collector restart +- With `sending_queue.storage` configured to a persistent storage extension, data is written to disk and recovered after a Collector restart - No silent data loss — failed sends are retried with backoff+extensions: + file_storage: + directory: /var/lib/otelcol/storage + exporters: otlp: endpoint: otlp.example.com:4317 sending_queue: enabled: true + storage: file_storage queue_size: 1000 @@ service: + extensions: [file_storage] pipelines: traces: receivers: [otlp] processors: [] exporters: [otlp]For OpenTelemetry Collector v0.151.0, does exporter `sending_queue` persist across restarts by default, and what exact config is required to enable disk-backed persistence and restart recovery?Also applies to: 71-93
🤖 Prompt for 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. In `@docs/tulip-lts-may2026-upgrade-plan.md` around lines 40 - 45, The docs imply exporter sending_queue is durable across restarts by default; update the text and examples to state that disk-backed persistence is not automatic and must be explicitly wired: add a storage extension entry under service.extensions (e.g., "storage") and set each exporter's sending_queue.storage to that extension id, and update the "After" example (and lines 71–93) to include a concrete storage extension config and sending_queue.storage reference so readers know how to enable disk-backed restart recovery for sending_queue and batch.
🤖 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.
Outside diff comments:
In `@test/start-otelcol.sh`:
- Around line 39-44: Update the retry/failure messages to reflect the new
readiness-by-log-marker strategy: replace the "Server still unavailable" append
into ./test/logs/test-${distribution}.log with a message like "Readiness marker
not found" (or similar), and change the failure echo that currently says "❌
FAIL. Server wasn't up after about 5s." to "❌ FAIL. Readiness marker not found
after about 5s." so the output and log use the readiness-marker terminology;
modify the lines that perform the echo to ensure they reference retries,
max_retries and the distribution variable unchanged.
---
Duplicate comments:
In `@docs/tulip-lts-may2026-upgrade-plan.md`:
- Around line 40-45: The docs imply exporter sending_queue is durable across
restarts by default; update the text and examples to state that disk-backed
persistence is not automatic and must be explicitly wired: add a storage
extension entry under service.extensions (e.g., "storage") and set each
exporter's sending_queue.storage to that extension id, and update the "After"
example (and lines 71–93) to include a concrete storage extension config and
sending_queue.storage reference so readers know how to enable disk-backed
restart recovery for sending_queue and batch.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: ollygarden/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 821ee7b5-ca3e-40e6-971d-ea6d73878f9e
📒 Files selected for processing (4)
distributions/tulip/tulip-test-docker.yamldistributions/tulip/tulip-test.yamldocs/tulip-lts-may2026-upgrade-plan.mdtest/start-otelcol.sh
✅ Files skipped from review due to trivial changes (1)
- distributions/tulip/tulip-test-docker.yaml
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
1 participant
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.
Tulip LTS May 2026
This PR prepares the Tulip LTS (Long-Term Support) release by upgrading all components to v0.151.0 and making targeted component changes to ensure production stability.
What is an LTS?
The upstream OpenTelemetry Collector ships new releases every ~2 weeks. The Tulip LTS provides a curated, validated baseline with extended support — giving production environments a stable target without upgrade fatigue.
Changes
Version bump
All components upgraded from v0.145.0 → v0.151.0, verified against the official otelcol-contrib manifest.
v0.151.0v1.57.0Component changes
Removed:
batchprocessorsending_queue+batchconfiguration, which provides durable queuing, crash recovery, and retry with backoffRemoved:
memorylimiterprocessormemorylimiterextensionRemoved:
healthcheckextensionAdded:
redactionprocessorAdded:
filestorageextensionAdded:
hostmetricsreceiverAdded:
filelogreceiverConfiguration updates
The default
config.yamlnow includes:sending_queuefor durable queuingbatchfor efficient batching at the export stageretry_on_failurewith exponential backoff on all network exportersmemory_limiterprocessor andhealth_checkextension referencesBug fix
test/generate-trace.sh(&>>→>> file 2>&1)Final component manifest (28 components)
Documentation
Full upgrade plan with migration guide available at
docs/tulip-lts-may2026-upgrade-plan.md.Validation
make generate-sources— PASSmake build— PASS (Tulip v0.151.0 compiles with all 28 components)make test— PASS (collector starts, traces generated and verified)Summary by CodeRabbit
New Features
Documentation
Chores
Tests
Bug Fixes