[chore][pprofiles] Fix pprofile DurationNano to be a TypeUint64#44397
[chore][pprofiles] Fix pprofile DurationNano to be a TypeUint64#44397mx-psi merged 13 commits intoopen-telemetry:mainfrom
Conversation
Complementary change to open-telemetry/opentelemetry-collector#14188. Signed-off-by: Florian Lehner <florian.lehner@elastic.co>
Signed-off-by: Florian Lehner <florian.lehner@elastic.co>
douglascamata
left a comment
There was a problem hiding this comment.
Thanks for taking the time to fix this!
| return ottl.StandardGetSetter[K]{ | ||
| Getter: func(_ context.Context, tCtx K) (any, error) { | ||
| return tCtx.GetProfile().Duration().AsTime(), nil | ||
| return tCtx.GetProfile().DurationNano(), nil |
There was a problem hiding this comment.
| return tCtx.GetProfile().DurationNano(), nil | |
| return time.Unix(0, int64(tCtx.GetProfile().DurationNano())).UTC(), nil |
This should continue returning time.Time, like before.
There was a problem hiding this comment.
I don't think this is a good idea. time.Time represents a point in time and not a duration. That is the whole point of open-telemetry/opentelemetry-collector#14188.
There was a problem hiding this comment.
If Duration and its return time.Time should stay, what is the procedure to mark it as deprecated and direct people to use DurationNano?
There was a problem hiding this comment.
My suggestion is to keep it returning time.Time for now (even if not ideal), so we don't need to delay this PR. We can handle this field deprecation and removal later in a separate breaking change issue.
There was a problem hiding this comment.
Requiring multiple breaking changes sounds like a lot of overhead, not only for the collector-contrib side.
With 4dbce06 I have aligned the changes.
There was a problem hiding this comment.
My suggestion was to not break it in this PR, the applied changes seems to be a breaking change, which isn't clear to users reading the added change log.
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description pcommon.Timestamp better represents a point in time rather than a duration. So keeping the proto field type for DurationNano is a better fit. Corresponding Collector-contrib change: open-telemetry/opentelemetry-collector-contrib#44397 ping @open-telemetry/profiling-approvers <!-- Issue number if applicable --> #### Link to tracking issue Fixes # <!--Describe what testing was performed and which tests were added.--> #### Testing <!--Describe the documentation added.--> #### Documentation <!--Please delete paragraphs that you did not use before submitting.--> --------- Signed-off-by: Florian Lehner <florian.lehner@elastic.co>
| return ottl.StandardGetSetter[K]{ | ||
| Getter: func(_ context.Context, tCtx K) (any, error) { | ||
| return tCtx.GetProfile().Duration().AsTime(), nil | ||
| return tCtx.GetProfile().DurationNano(), nil |
There was a problem hiding this comment.
I don't think this is a good idea. time.Time represents a point in time and not a duration. That is the whole point of open-telemetry/opentelemetry-collector#14188.
| return ottl.StandardGetSetter[K]{ | ||
| Getter: func(_ context.Context, tCtx K) (any, error) { | ||
| return tCtx.GetProfile().Duration().AsTime(), nil | ||
| return tCtx.GetProfile().DurationNano(), nil |
There was a problem hiding this comment.
If Duration and its return time.Time should stay, what is the procedure to mark it as deprecated and direct people to use DurationNano?
Co-authored-by: Vihas Makwana <121151420+VihasMakwana@users.noreply.github.com>
Signed-off-by: Florian Lehner <florian.lehner@elastic.co>
Signed-off-by: Florian Lehner <florian.lehner@elastic.co>
Signed-off-by: Florian Lehner <florian.lehner@elastic.co>
Co-authored-by: Pablo Baeyens <pbaeyens31+github@gmail.com>
|
I am going to merge this to avoid merge conflicts. @TylerHelmuth @evan-bradley @edmocosta I believe Florian addressed the OTTL asks satisfactorily but PTAL as codeowners! |
The merged OTTL changes are a braking change (changed a field type), and unfortunately we don't have a specific change log for that, which is not ideal, even considering the profile stability. I wish we could split this kind of PRs per components in the future, at least when meaningful code is modified. |
Wouldn't an API changelog work for that?
I am supportive of this, feel free to block the PR in the future if you'd rather the PR not be merged |
That's an I'm on PTO and will only have access to my computer next week, if someone else could apply this suggestion or add the change log, that would be great. @TylerHelmuth @evan-bradley @florianl? Thank you! |
|
I misunderstood your point, sorry. I created a release blocker issue based on your comment to add the entry, see #44560 |
Description
Complementary change to open-telemetry/opentelemetry-collector#14188.
Link to tracking issue
Fixes
Testing
Documentation