Merge branch 'main' into cijothomas/fix-hash

Author: cijothomas

.github/workflows/ci.yml

@@ -53,7 +53,7 @@ jobs:
   external-types:
     strategy:
       matrix:
-        example: [opentelemetry, opentelemetry-sdk]
+        example: [opentelemetry, opentelemetry-sdk, opentelemetry-otlp, opentelemetry-zipkin]
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4

.github/workflows/markdown-link-check.yml

@@ -15,7 +15,7 @@ jobs:
       - uses: actions/checkout@v4
 
       - name: Install markdown-link-check
-        run: npm install -g markdown-link-check
+        run: npm install -g markdown-link-check@3.11.2
 
       - name: Run markdown-link-check
         run: |

RELEASING.md

@@ -0,0 +1,52 @@
+# Releasing OpenTelemetry Rust
+
+The primary audience for this is the SIG Maintainers. It provides the list of steps for how to release the crates and the
+considerations to make before releasing the crate. It may provide use to consumers of the crate if/when we develop a
+release cadence.
+
+## Release cadence
+
+As of Feb 2024, there is no established cadence for the OpenTelemetry crates. The balance is required between too many
+breaking changes in a single release, and since we have instability flipping between implementations across 0.x
+releases. Perhaps once we've established a 1.0 we can consider adopting a consistent release cadence.
+
+## Considerations
+
+A draft PR can be created, but before releasing consider the following:
+
+* Are there any pending pull requests which should be included in the next release?
+  * Are they blockers?
+* Are there any unresolved issues which should be resolved before the next release?
+* Bring it up at a SIG meeting, this can usually get some of these questions answered sooner than later. It will also
+  help establish a person to perform the release. Ideally this can be someone different each time to ensure that the
+  process is documented.
+
+## Steps to Release
+
+1. Create a release PR
+  - For each crate
+    - Bump appropriate version
+    - Update change logs to reflect release version.
+    - Update API/SDK version as necessary
+    - Attach `integration test` label to the PR to run integration tests
+  - If there's a large enough set of changes, consider writing a migration guide.
+2. Merge the PR
+  - Get reviews from other Maintainers
+  - Ensure that there haven't been any interfering PRs
+3. Tag the release commit based on the [tagging convention](#tagging-convention). It should usually be a bump on minor version before 1.0
+4. Create Github Release
+5. [Publish](#publishing-crates) to crates.io using the version as of the release commit
+6. Post to [#otel-rust](https://cloud-native.slack.com/archives/C03GDP0H023) on CNCF Slack.
+
+
+## Tagging Convention
+
+For each crate: it should be `<crate-name>-<version>` `<version>` being the simple `X.Y.Z`.
+
+## Publishing Crates
+
+For now we use the [basic procedure](https://doc.rust-lang.org/cargo/reference/publishing.html) from crates.io.
+
+Follow this for each crate as necessary.
+
+For any new crates remember to add open-telemetry/rust-maintainers to the list.

opentelemetry-otlp/allowed-external-types.toml

@@ -0,0 +1,22 @@
+# Copyright The OpenTelemetry Authors
+# SPDX-License-Identifier: Apache-2.0
+# This is used with cargo-check-external-types to reduce the surface area of downstream crates from
+# the public API. Ideally this can have a few exceptions as possible.
+allowed_external_types = [
+    "opentelemetry::*",
+    "opentelemetry_http::*",
+    "opentelemetry_sdk::*",
+    # http is a pre 1.0 crate
+    "http::uri::InvalidUri",
+    "http::header::name::InvalidHeaderName",
+    "http::header::value::InvalidHeaderValue",
+    # prost is a pre 1.0 crate
+    "prost::error::EncodeError",
+    # tonic is a pre 1.0 crate
+    "tonic::status::Code",
+    "tonic::status::Status",
+    "tonic::metadata::map::MetadataMap",
+    "tonic::transport::channel::Channel",
+    "tonic::transport::error::Error",
+    "tonic::service::interceptor::Interceptor",
+]

opentelemetry-sdk/CHANGELOG.md

@@ -2,6 +2,10 @@
 
 ## vNext
 
+- Fix SimpleSpanProcessor to be consistent with log counterpart. Also removed
+  dependency on crossbeam-channel.
+  [1612](https://github.com/open-telemetry/opentelemetry-rust/pull/1612/files)
+
 ## v0.22.1
 
 ### Fixed

opentelemetry-sdk/Cargo.toml

@@ -14,7 +14,6 @@ opentelemetry = { version = "0.22", path = "../opentelemetry/" }
 opentelemetry-http = { version = "0.11", path = "../opentelemetry-http", optional = true }
 async-std = { workspace = true, features = ["unstable"], optional = true }
 async-trait = { workspace = true, optional = true }
-crossbeam-channel = { version = "0.5", optional = true }
 futures-channel = "0.3"
 futures-executor = { workspace = true }
 futures-util = { workspace = true, features = ["std", "sink", "async-await-macro"] }
@@ -45,9 +44,9 @@ pprof = { version = "0.13", features = ["flamegraph", "criterion"] }
 
 [features]
 default = ["trace"]
-trace = ["opentelemetry/trace", "crossbeam-channel", "rand", "async-trait", "percent-encoding"]
+trace = ["opentelemetry/trace", "rand", "async-trait", "percent-encoding"]
 jaeger_remote_sampler = ["trace", "opentelemetry-http", "http", "serde", "serde_json", "url"]
-logs = ["opentelemetry/logs", "crossbeam-channel", "async-trait", "serde_json"]
+logs = ["opentelemetry/logs", "async-trait", "serde_json"]
 logs_level_enabled = ["logs", "opentelemetry/logs_level_enabled"]
 metrics = ["opentelemetry/metrics", "glob", "async-trait"]
 testing = ["opentelemetry/testing", "trace", "metrics", "logs", "rt-async-std", "rt-tokio", "rt-tokio-current-thread", "tokio/macros", "tokio/rt-multi-thread"]

opentelemetry-sdk/src/logs/log_processor.rs

@@ -52,12 +52,10 @@ pub trait LogProcessor: Send + Sync + Debug {
     fn event_enabled(&self, level: Severity, target: &str, name: &str) -> bool;
 }
 
-/// A [`LogProcessor`] that exports synchronously when logs are emitted.
-///
-/// # Examples
-///
-/// Note that the simple processor exports synchronously every time a log is
-/// emitted. If you find this limiting, consider the batch processor instead.
+/// A [LogProcessor] that passes logs to the configured `LogExporter`, as soon
+/// as they are emitted, without any batching. This is typically useful for
+/// debugging and testing. For scenarios requiring higher
+/// performance/throughput, consider using [BatchLogProcessor].
 #[derive(Debug)]
 pub struct SimpleLogProcessor {
     exporter: Mutex<Box<dyn LogExporter>>,