-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Identify and move components from core to contrib to support trace stability milestone #3474
Comments
I suggest that we: Keep in the core:Exporters
Receivers:
Processors
Extensions:
Move to contrib:Exporters:
Receivers:
Processors
Extensions:
Thoughts @bogdandrutu @alolita ? |
|
|
I don't mind moving. Everybody happy with moving Prometheus receiver to contrib? |
Seems like OpenCensus is a pretty stable codebase and does not require much maintenance. I don't mind moving to contrib though if that's what we want. |
@tigrannajaryan this list looks like a good first start. A couple of concerns -
|
Since we are working on ensuring first-class Prometheus interoperability, I propose - Preferred Option: we keep the Prometheus components in core as-is where the Prometheus receiver, Prometheus remote write exporter (push-based) and Prometheus export (pull-based) stay in Collector core repo. At a minimum, we would like to see the Prometheus receiver and Prometheus remote write exporter in core to maintain stability criteria to ensure all PRW compliance tests are passing. Alternative Option - Since we are aiming for stability for core Collector functionality, I suggest we have a repo hosting all Prometheus components - Prometheus receiver, PRW exporter and Prometheus exporter (which needs some TLC). I don't think moving Prometheus components into contrib would be an optimal choice. Look forward to discussing any concerns, thoughts. |
This is a bit surprising. Is there a long term plan to remove this dependency? Could we imagine using an OTel-Go SDK? |
Yes, most likely that's what we will do. IIRC, we had some dependency conflicts that prevented us to do this easily. |
Can we have a wider audience for these discussions on metrics scraping rearchitecture? Sorry I missed the IIRC discussion. |
See #1093 |
I don't think we will be ready to move Prometheus receiver into contrib until the Go SDK is 1.0 (stable). |
Here is the current snapshot that @bogdandrutu and I discussed for list of components in core and to be moved to contrib. Stays in opentelemetry-collector
Move to opentelemetry-collector-contrib:
NOTE: Please note we're still discussing location of Prometheus components. |
@alolita we also discussed that we need to look more deeper into |
We talked in the past about having distributions as a concept that is unrelated to the code repositories. With that, we could keep the core without concrete receivers/exporters/processors, serving only as an API for downstream distributions (such as Jaeger v2). The core components could be located in a different repository, with distributions being built using the OpenTelemetry Collector Builder. The core distribution would include the components listed in this ticket here. Later on, we could have officially supported alternative distributions, such as a "sidecar" distribution containing only OTLP receivers/exporters. Are we still considering doing this? |
Adding more detail here for config modules which need to be evaluated for stability readiness. I will be opening issues for each tracking each component. - Done config/ has:
|
Why do we want to move |
As discussed during this week's SIG call, here's a draft proposal for splitting the concerns (API consumers vs. distribution users): https://docs.google.com/document/d/1XyYyaYtc1R8-es0BL65XE21dORLQpCPM1Pinw4MyEYs/edit |
I'd like to make a separate proposal: I believe we should combine core and contrib. core would be the API as a separate go module and then each component that was previously in core (zipkin, prometheus, etc.) would become its own go.mod component just like every other contrib module works. This could live in the same repository and prevent the whole "update core then go update contrib". I believe it'd streamline a lot of development. Things would still stay logically separated as they are separate go modules. I also described this here https://docs.google.com/document/d/1XyYyaYtc1R8-es0BL65XE21dORLQpCPM1Pinw4MyEYs/edit?disco=AAAANPPTudk |
@jrcamp why is it important that the core and contrib are in the same repository especially when core will become stable? |
I would like to see this, maybe all distributions are built from the "builder" repository. Maybe a short diagram of where things will be and in what module would help clarifying. Few things we need to do:
That's why I don't like issues in github and I think a short document would help us answer all the questions, I feel that everyone has the ideas in their mind but nobody put them all together to see the full picture. |
Just because it's stable doesn't mean new API's won't be added. What that rate will be though I don't really know. I guess I would flip the question and ask what benefit are we gaining by having them be separate? |
This is done. |
For the work left we filed separate issues. |
After discussion with the Collector maintainers, we plan to identify and move components from collector core to collector-contrib to support an imminent trace stability goal for the core Collector. This move will help us declare a stable Collector core.
This includes:
The text was updated successfully, but these errors were encountered: