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

Move carbonreceiver protocol package to an internal or pkg package #30465

Closed
atoulme opened this issue Jan 12, 2024 · 8 comments
Closed

Move carbonreceiver protocol package to an internal or pkg package #30465

atoulme opened this issue Jan 12, 2024 · 8 comments

Comments

@atoulme
Copy link
Contributor

atoulme commented Jan 12, 2024

Component(s)

receiver/carbon

Describe the issue you're reporting

The carbon receiver protocol package is used by the wavefrontreceiver.

We are trying to limit the API exposed by each collector component and move reusable code to internal or better, pkg packages. Would it be possible to make that change here?

@atoulme atoulme added the needs triage New item requiring triage label Jan 12, 2024
Copy link
Contributor

Pinging code owners:

See Adding Labels via Comments if you do not have permissions to add labels yourself.

@mx-psi
Copy link
Member

mx-psi commented Jan 12, 2024

to internal or better, pkg packages

Why is pkg better? I think we should prefer internal, since this limits usage by outside projects

@aboguszewski-sumo
Copy link
Member

Technically it should be no problem. However, there is this comment:

Type: "plaintext", // TODO: update after other parsers are implemented for Carbon receiver.

and the issue seems to be as old as the receiver, so at this point it seems to me as if existence of wavefront receiver as a separate receiver was a technical debt (correct me if I'm wrong).

Wouldn't in this case be better to deprecate wavefront receiver and recommend creating new parsers if you want to reuse the carbon receiver? Since this issue is so old, I don't know what was the original intention. The only thing I saw is that the wavefront receiver is indeed older than regex parser for carbon receiver (this vs this).

@atoulme
Copy link
Contributor Author

atoulme commented Jan 19, 2024

to internal or better, pkg packages

Why is pkg better? I think we should prefer internal, since this limits usage by outside projects

I imagined that there was so much value in the code it might interest folks to use it as a library. I meant it as a compliment.

internal is the right choice, agreed.

@mx-psi
Copy link
Member

mx-psi commented Jan 19, 2024

I imagined that there was so much value in the code it might interest folks to use it as a library. I meant it as a compliment.

😄 I see. For the record, my preference to make something internal is just to make it easier to maintain, not a judgement call on the library haha

@atoulme
Copy link
Contributor Author

atoulme commented Jan 19, 2024

No problem at all, just trying to entice people while I give them work :)

@crobert-1 crobert-1 added chore and removed needs triage New item requiring triage labels Jan 23, 2024
Copy link
Contributor

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

See Adding Labels via Comments if you do not have permissions to add labels yourself.

@github-actions github-actions bot added the Stale label Mar 25, 2024
Copy link
Contributor

This issue has been closed as inactive because it has been stale for 120 days with no activity.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale May 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants