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

[receiver/jmx] mark receiver as deprecated #9063

Conversation

codeboten
Copy link
Contributor

After many discussions it seems the community is leaning towards removing the components that execute subprocesses. As such, marking the JMX receiver as deprecated.

Related: #6750

If folks are ok with this path moving forward, I can follow this up with a PR to remove the component from the manifest in the releases repository in the next version.

Alex Boten added 2 commits March 31, 2022 13:20
After many discussions it seems the community is leaning towards removing the components that execute subprocesses. As such, marking the JMX receiver as deprecated.

Fixes open-telemetry#6750
@codeboten codeboten requested review from a team and mx-psi April 4, 2022 18:56
@djaglowski
Copy link
Member

While I generally agree with the concerns expressed by the community about running subprocesses, I did not think we had reached consensus to universally prohibit them. This receiver provides valuable functionality equivalent to a dozen scrapers and is not easily replaced.

Technically, we still have guidelines for running subprocesses as well as documentation describing this type of use case.

I don't want to drag on what has already been an intractable issue, but before this component is deprecated, I think we should establish whether we are prohibiting subprocesses in general vs defining stricter standards that allow for subprocesses under certain circumstances.

If we are not prohibiting subprocesses in general, then I think #6750 is still a relevant conversation. This comment seems to have articulated a strategy that would go a long way toward securing the component. Certainly there would be more to it as well. I'm happy to push on that thread if we are still open to keeping the component.

Copy link
Contributor Author

@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.

@djaglowski I've added this to the agenda for the SIG meeting tomorrow. I chatted with some of the maintainers/approvers about this last week and the general sense I got from that thread is that folks preferred moving in the direction of removing the components.

I'll wait until the discussion tomorrow before moving this PR, #9062, and #9058 forward.

Copy link
Member

@mx-psi mx-psi left a comment

Choose a reason for hiding this comment

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

I originally approved this, but I think one important thing missing from this PR is adding a //Deprecated: message to jmxreceiver's go.mod file: we want downstream distros to be aware of the removal

@codeboten
Copy link
Contributor Author

Closing this PR as per the comment: #6750 (comment)

@codeboten codeboten closed this Apr 6, 2022
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.

5 participants