-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
update config dependency #11611
base: main
Are you sure you want to change the base?
update config dependency #11611
Conversation
6f225b7
to
47f403a
Compare
Looking forward to seeing this get merged! |
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
Not stale? @codeboten |
47f403a
to
2a0e6f8
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #11611 +/- ##
==========================================
- Coverage 91.67% 91.64% -0.03%
==========================================
Files 461 462 +1
Lines 24749 24744 -5
==========================================
- Hits 22689 22677 -12
- Misses 1678 1681 +3
- Partials 382 386 +4 ☔ View full report in Codecov by Sentry. |
Could use some feedback from @open-telemetry/collector-approvers on this latest commit to the PR to update the config support from v0.2.0 to v0.3.0. tl;dr there's a backwards incompatible change in how headers are passed in and I wanted to support users transitioningi wanted to support both the 0.3.0 and the 0.2.0 schema, which resulted in some migration code. I still have a few tests to add, and this change will need a PR in go-contrib to be merged before it can be completely done. Anyways, i could use your input: df83265 This is waiting on open-telemetry/opentelemetry-go-contrib#6412 |
The approach to handle the backward incompatible change looks good to me 👍 |
// compatibility attempts | ||
return err | ||
} | ||
// TODO: add a warning log to tell users to migrate their config |
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 it might be complicated to pass a logger here, but it's pretty important. I think we should come up with a solution by the time we release this 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.
The way we do this on the Datadog exporter is to have a private field that is written to during unmarshaling and then a method to log warnings.
I don't love it, but I haven't been able to come up with anything better
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 appreciate your efforts to not break our current users. And explicitly about this:
Anyways, i could use your input: df83265
I like your approach. We don't have a schema version anywhere, so trying to fallback to the previous version before failing is a good approach. It doesn't scale nicely, but I also don't see a good way to determine the version other than requiring users to provide a schema version (which is bad UX for this specific place of the config, IMO).
@@ -363,3 +385,43 @@ func pdataFromSdk(res *sdkresource.Resource) pcommon.Resource { | |||
} | |||
return pcommonRes | |||
} | |||
|
|||
func disableHighCardinalityMetrics() []config.View { |
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.
looks OK for now, but if we expect this list to grow before we remove the gate, it might make sense to externalize this somehow?
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 is the purpose of #11754
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 this is a good opportunity to resolve #10808 by writing down what our plans are regarding this.
// compatibility attempts | ||
return err | ||
} | ||
// TODO: add a warning log to tell users to migrate their config |
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.
The way we do this on the Datadog exporter is to have a private field that is written to during unmarshaling and then a method to log warnings.
I don't love it, but I haven't been able to come up with anything better
@@ -363,3 +385,43 @@ func pdataFromSdk(res *sdkresource.Resource) pcommon.Resource { | |||
} | |||
return pcommonRes | |||
} | |||
|
|||
func disableHighCardinalityMetrics() []config.View { |
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 is the purpose of #11754
3bcf5f1
to
b0021fb
Compare
41beb42
to
e30a736
Compare
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
This change updates the dependency on go.opentelemetry.io/contrib/config to the latest in main. This is because v0.11.0 has a bug that prevents resource attributes to be applied as labels in the prometheus exporter. This change contains the following pieces: 1. the update of the dependency 2. add a layer to prevent breaking end users' configuration of exporter headers 3. move the meter provider initialization to depend on the config package instead of otelinit Number 3 didn't need to happen in this PR, but doing #2 required a bunch of changes that can be avoided by moving to using the meter provider from config instead of otelinit. Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
This allows end users to configure their internal metrics export with either the new v0.3.0 schema or the existing v0.2.0 schema. Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
c526989
to
40d3021
Compare
Signed-off-by: Alex Boten <[email protected]>
This PR does a couple of things that I couldn't quite split up so I put together a PR w/ individual commits to help reviewers get through it. This PR does the following:
go.opentelemetry.io/contrib/config
package to latest. this brings in breaking changes. in order to prevent those breaking changes from impacting end users, i've also added a layer of config unmarshalingotelinit
. the reason for including this change was that unmarshaling the config was causing circular dependencies i didn't want to address by moving code that could be deleted around.Replacement for #11458.
Fixes #12021