-
Notifications
You must be signed in to change notification settings - Fork 417
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
Proposal: Move Extra packages out of this repo into a opentelemetry-rust-contrib #841
Comments
I think that makes sense. The discussion around this before was worried about it will be harder to maintain two separate repos. We also publish a contrib crate that basically includes anything is not in standard but not complicate enough for a separate crate. |
It's not obvious to me why Jaeger, Prometheus and Zipkin are in core and the others aren't? |
Those exporters are defined in spec as something SDK should support. Another way to think about this is whether we want to maintain the model between this repo and contrib repo. Contrib repo is a great tool if some component is supported by a specific group of ppl. For example, AWS has been maintaining AWS x-ray in Java IIRC. |
Something like this could make sense as well. |
I think we should keep all the crates maintained by this org in a single workspace, so that we can benefit from centralized maintenance when core APIs change. I guess we could stuff some crates in a |
The most salient thing I can think of would be related to the MSRV and tying the "contribs" to the main could conflate the two. Granted I'm sure it would be good to keep a decent pace. Clarification that I don't mean at the crate level since thats where its set but in terms of CI. |
In the SIG we spoke about delaying this until at least trace and metrics are stable. Cc: @cijothomas @TommyCpp |
I understand we discussed this few months ago, but based on the discussions in the SIG meeting yesterday, want to make this happen sooner, to keep the repo only have the core-components needed to declare stable. There are too many components, and they make the CIs slow, and also take away focus from the core goal. Moving non-core to contrib repo should help keep more focus on core. (There is related topic of doing frequent, predictable release frequency as well.) |
FWIW, I've come around to the point of view that there's too much stuff in this repo and that it would make sense to split it up. I guess I might now lean the other direction and say that there should be one repo per more opinionated/smaller component, rather than a kind of -contrib dumping ground, mostly because as a maintainer I'd like to not get notifications from a bunch of stuff I don't care for anyway. So I wonder how big the core set should be? I'm guessing:
What else? |
The core - is what is defined by OTel Spec. Maintainers have freedom to host more in the main repo. OTel .NET maintainers decided to host 3 instrumentation libraries in the main repo. OTel Rust can also decide to specially keep some components here. (I am particularly interested in keeping tracing-appender for now, given we already have special treatment for tracing in our api). I might now lean the other direction and say that there should be one repo per more opinionated/smaller component These were also discussed in many other SIGs as well (and even followed in some open-census/tracing repos). The general practice seen so far in Otel is to have a single contrib repo to begin with, and if that gets too big, then spin off further to create more dedicated repos! I think this topic is something we'd want to comeback after the initial spun up of single contrib repo. |
My proposed list of components to be moved out to contrib repo:
|
Why do these exporters get to stay in the core, and the others don't? That seems fairly arbitrary. |
It's coming from the guidelines - https://github.com/open-telemetry/opentelemetry-specification/blob/v1.26.0/specification/library-guidelines.md#requirements
|
I've updated my description but also to note in the conversation. This should be the full list. Keep in Primary:
Move to Contrib:
Side note for the execution on this what ever we do, we should not lose the history for these crates in the new repo and there should be no reason to rewrite git history. |
Thanks @hdost . If okay with all, I'd like to request to keep opentelemetry-appender-tracing in the main repo for now. We are still figuring out whether that crate should be merged with tracing-opentelemetry crate, and also the potential of specially treating If we end up removing the create altogether, then its best to keep it here itself and nuke it later, as opposed to moving out to contrib and removing! |
This change will allow better examples directories as well as we can show more usage types without the total becoming unmaintainable 👍 |
Should we keep |
I am not opposed to it. We can still keep in contrib and maintain it. My comment about keeping appender-tracing here was more because "it is not settled that we'll need that crate or merge it into tracing-opentelemetry itself" |
Added comments about the two appenders. I've requested a new repo. In the community project. Once we have it, we should be able to progress. |
They have now been added in opentelemetry-rust-contrib Relates open-telemetry#841
They have now been added in opentelemetry-rust-contrib Relates open-telemetry#841 Signed-off-by: Harold Dost <h.dost@criteo.com>
They have now been added in opentelemetry-rust-contrib Relates open-telemetry#841 Signed-off-by: Harold Dost <h.dost@criteo.com>
They have now been added in opentelemetry-rust-contrib Relates open-telemetry#841 Signed-off-by: Harold Dost <h.dost@criteo.com>
They have now been added in opentelemetry-rust-contrib Relates open-telemetry#841 Signed-off-by: Harold Dost <h.dost@criteo.com>
They have now been added in opentelemetry-rust-contrib Relates open-telemetry#841 Signed-off-by: Harold Dost <h.dost@criteo.com>
Closing this as we now have two separate repos, and the contrib crates are moved. |
Following reading more on the IdGenerator I was also taking a look at some of the other language repos, and I wonder if there shouldn't be a
opentelemetry-rust-contrib
repo created to hold anything outside the "core".Updated on 2023-11-02 for consistency with the repo.
Keep in Primary:
opentelemetry
opentelemetry-http
opentelemetry-jaeger
opentelemetry-otlp
opentelemetry-prometheus
opentelemetry-proto
opentelemetry-sdk
opentelemetry-semantic-conventions
opentelemetry-stdout
opentelemetry-zipkin
opentelemetry-appender-log
- Forlog
which is a crate maintained by Rust Lang teamopentelemetry-appender-tracing
- Keep for now, might be deleted or merged intotracing-opentelemetry
laterMove to Contrib:
opentelemetry-aws
opentelemetry-contrib
opentelemetry-datadog
opentelemetry-dynatrace
opentelemetry-stackdriver
opentelemetry-user-events-logs
opentelemetry-user-events-metrics
opentelemetry-zpages
Source: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/sdk.md#id-generators
Java: https://github.com/open-telemetry/opentelemetry-java-contrib/tree/main/aws-xray
The text was updated successfully, but these errors were encountered: