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

Split pdata package by telemetry signal type #5087

Closed

Conversation

dmitryax
Copy link
Member

@dmitryax dmitryax commented Mar 25, 2022

This is an alternative to #4918 with the following package structure:

/model
  /pcommon (aliases to common API in /internal/pdata: Resource, Map, Value etc)
  /ptrace (aliases to traces API of internal/pdata)
  /plog (aliases to logs API of internal/pdata)
  /pmetric (aliases to metrics API of internal/pdata)

@dmitryax dmitryax requested a review from a team as a code owner March 25, 2022 07:24
@codecov
Copy link

codecov bot commented Mar 25, 2022

Codecov Report

Merging #5087 (f28481b) into main (caa4f27) will decrease coverage by 0.19%.
The diff coverage is 100.00%.

❗ Current head f28481b differs from pull request most recent head 762e945. Consider uploading reports for the commit 762e945 to get more accurate results

@@            Coverage Diff             @@
##             main    #5087      +/-   ##
==========================================
- Coverage   90.34%   90.14%   -0.20%     
==========================================
  Files         182      183       +1     
  Lines       11031    11022       -9     
==========================================
- Hits         9966     9936      -30     
- Misses        840      864      +24     
+ Partials      225      222       -3     
Impacted Files Coverage Δ
model/internal/pdata/generated_plog.go 96.65% <ø> (ø)
model/internal/pdata/generated_pmetric.go 97.00% <ø> (ø)
model/internal/pdata/generated_ptrace.go 96.89% <ø> (ø)
consumer/internal/consumer.go 100.00% <100.00%> (ø)
model/otlpgrpc/metrics.go 43.54% <0.00%> (-20.39%) ⬇️
model/otlpgrpc/logs.go 43.54% <0.00%> (-16.46%) ⬇️
model/otlpgrpc/traces.go 43.54% <0.00%> (-16.46%) ⬇️
model/otlp/json_unmarshaler.go 76.92% <0.00%> (-2.39%) ⬇️
config/mapprovider/filemapprovider/mapprovider.go 82.35% <0.00%> (-1.86%) ⬇️
config/configgrpc/configgrpc.go 92.68% <0.00%> (-0.25%) ⬇️
... and 14 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update caa4f27...762e945. Read the comment docs.

@dmitryax dmitryax marked this pull request as draft March 25, 2022 07:42
@dmitryax dmitryax force-pushed the split-pdata-alternative branch 2 times, most recently from 449d4b5 to c8471e8 Compare March 25, 2022 08:04
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 like this, except the split of consumer which is out of scope for the pdata split.

@dmitryax
Copy link
Member Author

Removed the split of consumer

@dmitryax dmitryax force-pushed the split-pdata-alternative branch 4 times, most recently from 9230a4f to 4b2a570 Compare March 29, 2022 20:44
@dmitryax dmitryax changed the title Create additional pdata packages separated by signal type (alternative structure) Split pdata package by telemetry signal type (alternative structure) Mar 29, 2022
@dmitryax dmitryax force-pushed the split-pdata-alternative branch 3 times, most recently from e153289 to 7b6470e Compare March 29, 2022 22:56
@dmitryax dmitryax marked this pull request as ready for review March 30, 2022 18:13
@dmitryax
Copy link
Member Author

dmitryax commented Mar 30, 2022

Based on the results of the poll (7:2), #4918 is closed in favor of this PR

@dmitryax dmitryax changed the title Split pdata package by telemetry signal type (alternative structure) Split pdata package by telemetry signal type Mar 30, 2022
@bogdandrutu
Copy link
Member

bogdandrutu commented Apr 1, 2022

@open-telemetry/collector-maintainers please review

Copy link
Contributor

@codeboten codeboten left a comment

Choose a reason for hiding this comment

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

Overall this looks good, just a couple of comments

CHANGELOG.md Outdated Show resolved Hide resolved
@dmitryax dmitryax force-pushed the split-pdata-alternative branch 2 times, most recently from 07f23e2 to e1f15ac Compare April 1, 2022 21:59
Copy link
Member

@tigrannajaryan tigrannajaryan left a comment

Choose a reason for hiding this comment

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

LGTM.

I think in our discussions we can continue referring to the internal data collectively as pdata even when it is totally eliminated from the codebase. It is a convenient and catchy name.

@dmitryax
Copy link
Member Author

dmitryax commented Apr 4, 2022

I think in our discussions we can continue referring to the internal data collectively as pdata even when it is totally eliminated from the codebase. It is a convenient and catchy name.

I agree on using pdata name as reference to the all pipeline data structures. We agreed on using p<signal> as module names, but we still can to move them under an extra pdata directory and have the following structure if we want to:

/model
  /pdata
    /pcommon (aliases to common API in /internal/pdata: Resource, Map, Value etc)
    /ptrace (aliases to traces API of internal/pdata)
    /plog (aliases to logs API of internal/pdata)
    /pmetric (aliases to metrics API of internal/pdata)
  /semconv
  ... 

@open-telemetry/collector-approvers please share you feedback if you think it'll be better.

@tigrannajaryan
Copy link
Member

We agreed on using p<signal> as module names, but we still can to move them under an extra pdata directory

This approach works for me too. No strong opinion one way or another.

@bogdandrutu
Copy link
Member

@dmitryax @tigrannajaryan what about a model -> pdata than semconv is it's own thing outside pdata module.

@dmitryax
Copy link
Member Author

dmitryax commented Apr 4, 2022

what about a model -> pdata than semconv is it's own thing outside pdata module.

I was also thinking about it. It means that we need to move model/otlp and model/otlpgrpc to pdata/p<signal>, right? I can submit a followup PR to see how it looks.

@tigrannajaryan
Copy link
Member

@dmitryax @tigrannajaryan what about a model -> pdata than semconv is it's own thing outside pdata module.

We have other packages in model which strictly speaking are not pdata unless we stretch the term (which I would prefer not to). pdata in my mind is in-memory representation of Collector pipeline data.

@bogdandrutu
Copy link
Member

I was also thinking about it. It means that we need to move model/otlp and model/otlpgrpc to pdata/p, right? I can submit a followup PR to see how it looks.

See #5027

We have other packages in model which strictly speaking are not pdata unless we stretch the term (which I would prefer not to). pdata in my mind is in-memory representation of Collector pipeline data.

Besides semconv nothing after we fix #5027

@Aneurysm9
Copy link
Member

We have other packages in model which strictly speaking are not pdata unless we stretch the term (which I would prefer not to). pdata in my mind is in-memory representation of Collector pipeline data.

This is how I think of it as well. It seems sufficiently different from OTLP, even if it is presently implemented as an API for managing an OTLP representation, that I think we should be careful about intermixing the concepts too much.

@dmitryax
Copy link
Member Author

dmitryax commented Apr 6, 2022

Looks like we have an agreement on how to merge otlp and otlpgrpc packages into pdata in #5027. According to that we will have the following modules instead if /model:

/pdata
  /ptrace (module)
    /ptraceotlp
  /pmetric (module)
    /pmetricotlp
  /plog (module)
    /plogotlp

/semconv (module)

If everyone is ok with this structure, I'm going to proceed with the following action items:

  1. Move /model/internal to /internal
  2. Update this PR to have /pdata/p<signal> instead of /model/p<signal>
  3. Address Split otlp/otlpgrpc #5027 by introducing /model/p<signal>/p<signal>oltp packages

cc @bogdandrutu @tigrannajaryan @Aneurysm9

@dmitryax dmitryax marked this pull request as draft April 6, 2022 18:10
@dmitryax
Copy link
Member Author

dmitryax commented Apr 6, 2022

I tried a RP for (1) item #5161. It works but introduces interdependencies between go.opentelemetry.io/collector and go.opentelemetry.io/collector/model modules. So I'd rather update this PR in a different way to avoid the interdependencies but use more aliasing for the deprecated APIs.

@dmitryax
Copy link
Member Author

dmitryax commented Apr 8, 2022

It appeared to be pretty difficult to do what we agreed on by the steps that I outlined without introducing interdependencies between modules. To make it in a clean way, splitting of all the pdata related parts into a new module has to be done in one shot. I submitted another PR for that instead of reusing this one: #5168

@dmitryax dmitryax deleted the split-pdata-alternative branch April 12, 2022 00:32
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.

None yet

5 participants