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

update OTLP to v0.8.0 #3572

Merged
merged 7 commits into from
Jul 8, 2021

Conversation

codeboten
Copy link
Contributor

@codeboten codeboten commented Jul 6, 2021

@codeboten
Copy link
Contributor Author

I've started the work to upgrade OTLP here, but I would like some feedback from @open-telemetry/collector-approvers on the way to proceed forward. The linter is currently failing because of various deprecated types still in use:

pdata/metrics.go:193:58: SA1019: otlpmetrics.IntGauge is deprecated: Do not use. (staticcheck)
                ms.orig.Data = &otlpmetrics.Metric_IntGauge{IntGauge: &otlpmetrics.IntGauge{}}
                                                                       ^
pdata/metrics.go:197:54: SA1019: otlpmetrics.IntSum is deprecated: Do not use. (staticcheck)
                ms.orig.Data = &otlpmetrics.Metric_IntSum{IntSum: &otlpmetrics.IntSum{}}
                                                                   ^
pdata/metrics.go:201:66: SA1019: otlpmetrics.IntHistogram is deprecated: Do not use. (staticcheck)
                ms.orig.Data = &otlpmetrics.Metric_IntHistogram{IntHistogram: &otlpmetrics.IntHistogram{}}
                                                                               ^
pdata/metrics.go:261:51: SA1019: otlpmetrics.IntGauge is deprecated: Do not use. (staticcheck)
                data := &otlpmetrics.Metric_IntGauge{IntGauge: &otlpmetrics.IntGauge{}}
                                                                ^
pdata/metrics.go:269:47: SA1019: otlpmetrics.IntSum is deprecated: Do not use. (staticcheck)
                data := &otlpmetrics.Metric_IntSum{IntSum: &otlpmetrics.IntSum{}}
                                                            ^
pdata/metrics.go:277:59: SA1019: otlpmetrics.IntHistogram is deprecated: Do not use. (staticcheck)
                data := &otlpmetrics.Metric_IntHistogram{IntHistogram: &otlpmetrics.IntHistogram{}}
                                                                        ^
pdata/metrics_test.go:47:17: SA1019: otlpmetrics.IntGauge is deprecated: Do not use. (staticcheck)
                                        IntGauge: &otlpmetrics.IntGauge{},
                                                   ^
pdata/metrics_test.go:63:15: SA1019: otlpmetrics.IntSum is deprecated: Do not use. (staticcheck)
                                        IntSum: &otlpmetrics.IntSum{},
                                                 ^
pdata/metrics_test.go:79:21: SA1019: otlpmetrics.IntHistogram is deprecated: Do not use. (staticcheck)
                                        IntHistogram: &otlpmetrics.IntHistogram{},
                                                       ^
pdata/metrics_test.go:441:26: SA1019: otlpmetrics.IntDataPoint is deprecated: Do not use. (staticcheck)
                                                                                DataPoints: []*otlpmetrics.IntDataPoint{
                                                                                               ^
pdata/metrics_test.go:776:20: SA1019: otlpmetrics.IntDataPoint is deprecated: Do not use. (staticcheck)
                                DataPoints: []*otlpmetrics.IntDataPoint{

Would it be better for me to continue working through those messages in this PR or disable the linter for SA1019 to allow this code to merge and prevent the PR from getting too large? Happy to go either ways here.

@tigrannajaryan
Copy link
Member

Thanks for starting this @codeboten !

We can probably silence the linter temporarily.

However, I think we need a more elaborate plan for this change.

Changing this repo is relatively easy. I think contrib is going to be much bigger volume of changes. We need to time the change such that it is fully doable in the period between the releases (2 weeks). Perhaps once this PR is ready, don't merge it yet, prepare the PR for corresponding contrib changes and only after ensuring contrib is also ready to be merged move forward. Contrib changes may turn out to be a lot of work and we may need to ask codeowners of each component to prepare a PR for their own component (or maybe not if it turns out to be not as laborious as I am imagining).

@codeboten
Copy link
Contributor Author

I tested the contrib repo with the changes as they are in this PR currently and things worked, this is expected as I'm not yet renaming things in pdata. We could potentially move ahead with this PR, which gives us at least the new protos and is not too hard to review.

The remaining items in the checklist could be tackled in following PRs and potentially even done in parallel. Thoughts @tigrannajaryan & @bogdandrutu?

@codeboten codeboten marked this pull request as ready for review July 7, 2021 19:53
@codeboten codeboten requested review from a team and dmitryax July 7, 2021 19:53
Copy link
Member

@bogdandrutu bogdandrutu left a comment

Choose a reason for hiding this comment

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

I would not "fix" #3534 since this change indeed does the upgrade, but does not do the right transformations to/from deprecated fields/metric types.

Comment on lines +137 to +138
# disabling to suppress deprecation warnings when updating OTLP to v0.8.0
# in support of breaking up the work into more manageable PRs
Copy link
Member

Choose a reason for hiding this comment

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

We should create an issue, or document this in #3534 that is left to deal with for later.

@tigrannajaryan
Copy link
Member

Reading the proto changes in 0.8.0 it seems like the wire format changes are not breaking? From what I see it should remain wire-format compatible with previous version (fields in some messages are added but not removed and some messages are renamed - all of which is backward compatible). Is that correct or I am missing a breaking change?

@@ -1192,18 +1192,18 @@ func (es DoubleDataPointSlice) RemoveIf(f func(DoubleDataPoint) bool) {
// Must use NewDoubleDataPoint function to create new instances.
// Important: zero-initialized instance is not valid for use.
type DoubleDataPoint struct {
Copy link
Member

Choose a reason for hiding this comment

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

What's the future plan? Will this struct be renamed NumberDataPoint?

Copy link
Member

Choose a reason for hiding this comment

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

Yes

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I plan on renaming this next and tackling removing IntDataPoint at the same time.

Comment on lines 1235 to 1237
func (ms DoubleDataPoint) Value() float64 {
return (*ms.orig).Value
return (*ms.orig).GetAsDouble()
}
Copy link
Member

Choose a reason for hiding this comment

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

Do we plan to remove Value and expose 2 different types of values, the int and the double in a future PR?

Copy link
Member

Choose a reason for hiding this comment

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

Yes

Copy link
Member

@bogdandrutu bogdandrutu left a comment

Choose a reason for hiding this comment

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

I think we can merge this and do the rest of the work in followup PRs

@bogdandrutu bogdandrutu merged commit 642a8e0 into open-telemetry:main Jul 8, 2021
@codeboten codeboten deleted the codeboten/proto-v0.8.0 branch July 8, 2021 19:53
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.

3 participants