-
Notifications
You must be signed in to change notification settings - Fork 32
Fix definition of composable parent threshold sampler #427
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
Merged
Merged
Changes from 2 commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
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
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
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
Oops, something went wrong.
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.
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.
If I understand, ComposableParentThreshold accepts a parameter
root, but since it accepts only one parameter, you're shortcutting it and just saying that whatever object is set is theroot.So in the following example,
always_onis theroot.If so, I think this breaks consistency and we should opt for a more verbose, yet consistent alternative:
It does looks silly. But its possible that ComposableParentThreshold adds additional parameters in the future. Also, a user familiar with the schema might go looking for the ComposableParentThreshold type in the schema and the
rootparameter, and be surprised not to find it since they find types for every other named sampler.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 guess this is the same as the schema compression I did for
composite/developmentso we'd probably need to update it too to match if going with it.https://github.com/open-telemetry/opentelemetry-configuration/blob/main/schema/tracer_provider.yaml#L84
Though maybe that looks a bit too weird to even consider. If we can make a decision to simplify the types for
composite/development, it may give some precedence to doing it forparent_thresholdas well.I've been erring on making the configs simpler than not since it seems easier to use that way. Generally I've had a user reading docs or looking at example yaml files in mind with the schema being an implementation detail of the yaml - a user actually looking for types in the schema didn't come to mind, but I suspect it's not really a common case.
Future additional arguments is definitely a good reason, but at the same time given how stable the Sampler APIs have been so far, I expect it to be similar for the new ones, basically no changes, even additive, after being marked
stable. I lean towards keeping the yaml simpler vs speculating on that.But I understand the arguments for including
rootas well and just don't lean towards it - @jack-berg if you still feel it's better though then I'll make the change.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 think we've got to go with having a
rootproperty. In addition to the arguments discussed, language implementations are going to tooling that expects SDK extension plugin types to be handled in a particular way. Changing the pattern will throw a wrench in that tooling in the few places we end up with deviations.We have prior are inSimple{LogRecord|Span}Processors have a single property named
exporter:Maybe. The distinction between ComposableSampler and CompositeSampler at the spec level is strange. Do we need both in declarative config? Can we get away with just ComposableSampler? Mabye we can:
.tracer_provider.composable_sampler/developmentproperty, of typeExperimentalComposableSampler.tracer_provider.composable_sampler/developmentOR.tracer_provider.samplercan be specified, but specifying both is an error..tracer_provider.composable_sampler/developmentinstead.(Aside: #397 would really help with evaluation of these types of things because we could ask PRs to include a snippet so we're all on the same page about the UX.)
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.
Ok, I added
rootforExperimentalComposableParentThresholdSampler. I didn't touchcomposite/developmentfor this PR. I think your proposal for it is a good one - but it makes me think of the relation between SDK and declarative config a bit more. My prediction for JavaCompositeSamplerin incubator until composable samplers are markedstableComposableSamplerwithout makingCompositeSamplerpublicsetSampler(ComposableSampler sampler)overload. It's easy and captures the 1-or-other semantics perfectly with Java idioms. The implementation of this would use internalCompositeSamplerBut for languages like Go that don't support overloads, I don't know whether they would go with
CompositeSamplerdelegate in long term, orSetComposableSamplertype of different-named overload, or both. Any of these seem reasonable, but different from Java.So it seems inevitable that there will be some divergence in how SDKs implement config in some cases. One issue with the proposal vs just having
sampler: composite/development: ...is having to document in comments which fields must not be set together instead of in schema (at least not wacky schema, I'm not familiar with every feature of JSON schema ;) ),compositesomehow avoids that. It would almost assuredly not be the right approach for the Java SDK itself though where overloads are idiomatic.Going back to
root, I'm fine with keeping consistency withexporterin the processors config, but if it were deemed the config experience improves by not having any of those, I would sort of expect SDKs to manage to implement it somehow as it's an implementation detail, similar to wherever we land with composite. Just 2cThere 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 all of this. ComposableSampler is essentially SamplerV2.
👍
Yeah we rely on comments a decent amount to communicate semantics and interactions between properties to both users and implementation maintainers. Some examples:
.compositeand.composite_list.attributesand.attributes_list.attribute_limits(same with.logger_provider.limits).headersand.headers_listI've gotten comfortable with
descriptionbeing a key part of the data model, and us needing to be careful to not break users when changing description contents. Maybe long term we can deprecate.tracer_provider.samplerso there's only one recommended way of doing things.👍 yeah its definitely possible for implementations to absorb this