health: Use opentelemetry crate rather than vendoring our own protos - #4723
health: Use opentelemetry crate rather than vendoring our own protos#4723kensimon wants to merge 2 commits into
Conversation
There's already a supported upstream crate, opentelemetry_proto, which has the same types we're vendoring with .proto files, so we can just use that. It's a drop-in replacement but has convenience converters for types we need.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (3)
Summary by CodeRabbit
WalkthroughThe health crate now uses ChangesOTLP migration
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
Cargo.toml (1)
59-59: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winRestrict
opentelemetry-prototo the required features.
crates/health/src/otlpuses generated tonic clients for logs and metrics. Setdefault-features = falseand enable["gen-tonic", "logs", "metrics"]. This avoids the unusedtrace,zpages,with-serde, andinternal-logsfeatures.🤖 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 `@Cargo.toml` at line 59, Update the opentelemetry-proto dependency declaration to disable default features and explicitly enable only gen-tonic, logs, and metrics, preserving the existing version.Sources: Coding guidelines, Path instructions
🤖 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.
Nitpick comments:
In `@Cargo.toml`:
- Line 59: Update the opentelemetry-proto dependency declaration to disable
default features and explicitly enable only gen-tonic, logs, and metrics,
preserving the existing version.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 4622101c-dd26-4bc2-92c3-3fc0d668eaba
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (11)
Cargo.tomlcrates/health/Cargo.tomlcrates/health/build.rscrates/health/proto/opentelemetry/proto/collector/logs/v1/logs_service.protocrates/health/proto/opentelemetry/proto/collector/metrics/v1/metrics_service.protocrates/health/proto/opentelemetry/proto/common/v1/common.protocrates/health/proto/opentelemetry/proto/logs/v1/logs.protocrates/health/proto/opentelemetry/proto/metrics/v1/metrics.protocrates/health/proto/opentelemetry/proto/resource/v1/resource.protocrates/health/src/otlp/convert.rscrates/health/src/otlp/mod.rs
💤 Files with no reviewable changes (7)
- crates/health/proto/opentelemetry/proto/logs/v1/logs.proto
- crates/health/proto/opentelemetry/proto/collector/metrics/v1/metrics_service.proto
- crates/health/proto/opentelemetry/proto/collector/logs/v1/logs_service.proto
- crates/health/proto/opentelemetry/proto/resource/v1/resource.proto
- crates/health/proto/opentelemetry/proto/metrics/v1/metrics.proto
- crates/health/proto/opentelemetry/proto/common/v1/common.proto
- crates/health/build.rs
There's already a supported upstream crate, opentelemetry_proto, which has the same types we're vendoring with .proto files, so we can just use that. It's a drop-in replacement but has convenience converters for types we need.
Related issues
#4712
Type of Change
Breaking Changes
Testing
Additional Notes
Note: I had originally thought this was going to be a clearer win... but ultimately it's pretty much identical to what we're doing now, with just slightly less data in this repo (not that vendoring a proto file is a huge deal.) I was hoping to use the richer types from the
opentelemetrycrate, but they're difficult to mix with opentelemetry_proto (for instanceopentelemetry::KeyValuehas a lot of friendly stuff but is still a distinct type from theopentelemetry_protoversion of it, andopentelemetry_protodoesn't really provide a ton of helpers.)Ultimately this is only a minor win over what we have now and it's pretty low-priority to merge.