-
Notifications
You must be signed in to change notification settings - Fork 164
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this on the critical path for OTel tracing 1.0?
|
||
This is a request for a general direction approval. There are a few principles for the development: | ||
|
||
1. zPages MUST NOT be hardcoded into OpenTelemetry SDK. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean by "not be hardcoded"? Something like this?
1. zPages MUST NOT be hardcoded into OpenTelemetry SDK. | |
1. zPages MUST NOT be enabled or configured by default in the OpenTelemetry SDK. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or does this mean it must be supplied in a separate package/code unit rather than "weaved into" the SDK?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SergeyKanzhelev Please clarify.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with your interpretation about making zPages a separate package / code unit, at the level of a span processor (for tracing). In OpenCensus, the zPages support was baked-in to the default SDK tracer. This relates to open-telemetry/opentelemetry-specification#373 about having access to live, unfinished spans.
This is a request for a general direction approval. There are a few principles for the development: | ||
|
||
1. zPages MUST NOT be hardcoded into OpenTelemetry SDK. | ||
2. OpenTelemetry implementation of zPages MUST be split as two separate components - one for data, another for rendering. So that, for example, data providers could be also integrated into other rendering frameworks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2. OpenTelemetry implementation of zPages MUST be split as two separate components - one for data, another for rendering. So that, for example, data providers could be also integrated into other rendering frameworks. | |
2. OpenTelemetry implementation of zPages MUST be split into two separate components - one for data collection and handling, another for rendering. This way, for example, data providers could be also integrated into other rendering frameworks. |
My impression is that it's not. @SergeyKanzhelev could you clarify this one? (maybe also mention this in the experimental folder PR). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM to go ahead.
@carlosalberto @jmacd no, it's not on the path for 1.0. |
* zPages proposal * renamed file to the PR number * linter issues * linter issues * added some principles for zPages development * fixes after Reiley review
* zPages proposal * renamed file to the PR number * linter issues * linter issues * added some principles for zPages development * fixes after Reiley review
* zPages proposal * renamed file to the PR number * linter issues * linter issues * added some principles for zPages development * fixes after Reiley review
* zPages proposal * renamed file to the PR number * linter issues * linter issues * added some principles for zPages development * fixes after Reiley review
No description provided.