Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify OTLP/HTTP endpoint configuration option handling #3739

Merged
merged 17 commits into from
Nov 28, 2023

Conversation

pellared
Copy link
Member

@pellared pellared commented Oct 26, 2023

  1. The specification should define how the configuration options should handle the value. We cannot force the user to not set an env var value.
  2. Changed endpoint to option to make it more clear that the specification says how the configuration option should work.
  3. Initially I thought about defining MUST not accept a path that contains other parts (instead of MAY), but I have not found any OTLP exporter that makes such a detailed validation (Java, .NET, Python). I was even considering to remove this statement, but I feel that it may be a too drastic change.

@pellared pellared changed the title Clarify OTLP exporter configuration endpoints handling Clarify OTLP exporter endpoints configuration options handling Oct 26, 2023
@pellared pellared marked this pull request as ready for review October 26, 2023 09:12
@pellared pellared requested review from a team October 26, 2023 09:12
@pellared pellared requested a review from pirgeo October 31, 2023 10:59
@pellared pellared requested a review from MrAlias November 2, 2023 14:57
@pellared pellared changed the title Clarify OTLP exporter endpoints configuration options handling Clarify OTLPHTTP exporter endpoint configuration option handling Nov 14, 2023
@pellared pellared changed the title Clarify OTLPHTTP exporter endpoint configuration option handling Clarify OTLP/HTTP exporter endpoint configuration option handling Nov 14, 2023
@pellared pellared changed the title Clarify OTLP/HTTP exporter endpoint configuration option handling Clarify OTLP/HTTP endpoint configuration option handling Nov 14, 2023
specification/protocol/exporter.md Outdated Show resolved Hide resolved
specification/protocol/exporter.md Outdated Show resolved Hide resolved
specification/protocol/exporter.md Outdated Show resolved Hide resolved
@pellared
Copy link
Member Author

@pirgeo @jack-berg @MrAlias Can please you take another look?

specification/protocol/exporter.md Outdated Show resolved Hide resolved
specification/protocol/exporter.md Outdated Show resolved Hide resolved
Copy link
Member

@tigrannajaryan tigrannajaryan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@carlosalberto carlosalberto merged commit ccd36cf into open-telemetry:main Nov 28, 2023
7 checks passed
@pellared pellared deleted the patch-10 branch November 28, 2023 17:59
carlosalberto pushed a commit to carlosalberto/opentelemetry-specification that referenced this pull request Oct 31, 2024
…try#3739)

1. The specification should define how the configuration options should
handle the value. We cannot force the user to not set an env var value.
2. Changed `endpoint` to `option` to make it more clear that the
specification says how the configuration option should work.
3. Initially I thought about defining `MUST not accept a path that
contains other parts` (instead of `MAY`), but I have not found any OTLP
exporter that makes such a detailed validation
([Java](https://github.com/open-telemetry/opentelemetry-java/blob/main/exporters/common/src/main/java/io/opentelemetry/exporter/internal/ExporterBuilderUtil.java),
[.NET](https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/OtlpExporterOptions.cs),
[Python](https://github.com/open-telemetry/opentelemetry-python/blob/main/exporter/opentelemetry-exporter-otlp-proto-http/src/opentelemetry/exporter/otlp/proto/http/trace_exporter/__init__.py)).
_I was even considering to remove this statement, but I feel that it may
be a too drastic change._
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants