-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
[receiver/jmx] mark receiver as deprecated #9063
Conversation
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
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. |
There was a problem hiding this 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.
There was a problem hiding this 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
Closing this PR as per the comment: #6750 (comment) |
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.