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.
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
Default Resource should have service.name attribute #1744
Default Resource should have service.name attribute #1744
Changes from 3 commits
4517454
493a855
e5a5c91
7144e11
aa9cfb6
86f9ffa
6cef7fd
bc22109
c0866b1
ebad31c
589499a
f76f9a1
667f3dc
eb72c99
dc5f09b
58f9e09
f985843
12225c1
429a031
7e0be45
d8d0d53
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 should stick with the casing "Sdk" since it is used elsewhere (eg
AddTelemetrySdk
).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.
Also, do we need a
CreateSdk
? How will user know which one to call (CreateDefault()
orCreatedSdk()
)? Probably better for us to give them just one path (pit of success).What if we combined both into one thing?
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.
Will fix the Sdk casing immediately. I like the idea of the optional parameter on default. This way we'll always have service.name and then optionally include the Telemetry SDK resource.
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.
AddTelemetrySdk
already exists on ResourceBuilder extensions, so why need it here again?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 not where we would provide access to the Telemetry Resource? We previously used CreateDefault to just link directly to AddTelemetrySDK
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.
Users just need an API to add TelemetrySDK, which we already provide. There is no need of an additional method.
A user can do:
ResourceBuilder.CreateEmpty().AddTelemetrySdk() - Resource will only have telemetrysdk attributes.
or
ResourceBuilder.CreateDefault().AddTelemetrySdk() - Resource will have telemetrysdk attributes + the default. (default is service.name("unknownservice..."))
or
ResourceBuilder.CreateDefault().AddTelemetrySdk().AddServiceName("CijoService") - Resource will have telemetrysdk attributes + service.name ("CijoService"). Due the merge priority, "CijoService" overrides the default one.
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.
This thinking makes a lot of sense to me. I'll remove the various extra things we introduced in this PR, and I like @CodeBlanch 's approach too but I think this is more elegant. Will not be implementing the optional parameter.