open-telemetry
Move opentelemetry-semconv version management to opentelemetry-bom
Is your feature request related to a problem?
It is about general dependency management hygiene and logical organization of it: what do you think about moving semconv's (io.opentelemetry.semconv/opentelemetry-semconv) dependency management from opentelemetry-instrumentation-bom to opentelemetry-bom?
From user perspective, opentelemetry-semconv should be next to opentelemetry-api (BOM-wise) since they are providing OTel "~interfaces" and both can be used without the Java instrumentation. This would also help making semconv more loosely coupled (one of OTel's core values) since right now, (logically/BOM-wise) it is a bit more coupled to instrumentation since it is in that BOM.
Describe the solution you'd like
Moving semconv's dependency management to opentelemetry-bom. Right now it is in opentelemetry-instrumentation-bom (see here) and semconv is used by users without instrumentation.
Describe alternatives you've considered
Not sure there is much, there are only two places for it, the current and opentelemetry-bom that I think is a better fit.
Additional context
I think this would not be a breaking change for users since opentelemetry-instrumentation-bom brings in opentelemetry-bom.
Does anyone has any thoughts on this? I think this is a rather important issue since it kind of violates one of the core values of OTel:
Telemetry should be loosely coupled OpenTelemetry end-users should be able to pick and choose from the pieces they want without bringing in the rest of the project. To enable this, OpenTelemetry’s software architecture is decoupled wherever possible. As a corollary, this also means that OpenTelemetry does not want to “pick winners” when it comes to particular projects or technologies: where possible, we prefer to give our end-users a choice.
(see here)
I know this is about BOMs but they represent the parts of OTel you need: opentelemetry-bom vs. opentelemetry-instrumentation-bom.
I support this, for the stable semconv packages. We have a problem where spring boot brings in the opentelemetry-bom, but we want to use the semconv. So now we have to align spring boot, otel SDK, and otel instrumentation BOMs altogether, it's very prone to error when upgrading versions. Something like Spring Boot can't use the instrumentation BOM because it would cause a circular dependency, see: https://github.com/spring-projects/spring-boot/issues/46201.
From user perspective, opentelemetry-semconv should be next to opentelemetry-api (BOM-wise) since they are providing OTel "~interfaces" and both can be used without the Java instrumentation.
This is a great point from @jonatan-ivanov, and I fully agree. Logically, the semconv would be used alongside the API, from an OTel user's perspective. If I'm not importing instrumentation, but importing just the semconv, I shouldn't need to think about the instrumentation BOM.
@trask @jack-berg do you have any thoughts on this?
I don't think circular dependencies are a problem for BOMs. If they are, gradle lets you publish them just fine. Here's a commit which adds a dependency from opentelemetry-bom to spring-boot-dependencies, which depends on opentelemetry-bom.
Of course there's a prioritization problem BOMs in the cycle have conflicting versions of dependencies.
Also, opentelemetry-semconv depends on opentelemetry-api, and an older version of opentelemetry-api than is managed in opentelemetry-bom. So if cycles and version conflicts are a problem, we're not exempt from them with this proposal.
But let's put that aside because it doesn't seem appropriate for spring boot bom to manage versions for a wider scope that it needs.
From user perspective, opentelemetry-semconv should be next to opentelemetry-api (BOM-wise) since they are providing OTel "~interfaces" and both can be used without the Java instrumentation. This would also help making semconv more loosely coupled (one of OTel's core values) since right now, (logically/BOM-wise) it is a bit more coupled to instrumentation since it is in that BOM.
I don't find this argument of looser coupling convincing. Right now, opentelemetry-bom is completely decoupled from instrumentation. Adding management of io.opentelemetry.semconv/opentelemetry-semconv more tightly couples it to semantic conventions than is strictly needed. Ignoring opentelemetry-java-instrumentation for a second, right now a user directly depending on opentelemetry-bom and the API gets to make a choice about which version of io.opentelemetry.semconv/opentelemetry-semconv they depend on independent of the API.
If we do decide to bundle io.opentelemetry.semconv/opentelemetry-semconv in with opentelemetry-bom, it will be purely out of convenience since there is no coupling / dependency between any component in opentelemetry-java and io.opentelemetry.semconv/opentelemetry-semconv.
If I'm not importing instrumentation, but importing just the semconv, I shouldn't need to think about the instrumentation BOM.
The argument I would make is that such a user should independently select the the version of semconv and of the API they depend on.
But with io.opentelemetry.semconv/opentelemetry-semconv now stable, a lot of the issues that might arise with including it in opentelemetry-bom go away:
- You want to choose a more recent version of
opentelemetry-semconvthan is included in theopentelemetry-bomversion you're using? Great, go ahead. - You want to choose an older version of
opentelemetry-semconvthan is included in theopentelemetry-bomversion you're using? Well you can do that, but there's no reason to because of our backwards compatibility guarantees. - You want to choose a different version of
opentelemetry-semconv-incubatingthan theopentelemetry-semconvversion that is included in theopentelemetry-bomversion you're using? That's fine as long as theopentelemetry-semconvversion is greater than theopentelemetry-semconv-incubatingversion.
So for me its just a question of whether including io.opentelemetry.semconv/opentelemetry-semconv in opentelemetry-bom is convenient for users. I think yes - its one less version to think about, and if you do care about the version, I don't believe including it in opentelemetry-bom does any harm.
Currently, as noted, there is no dependency between any component in opentelemetry-java and opentelemetry-semconv. With a stable opentelemetry-semconv artifact, we might consider loosening that and replacing our copies of things like exception.* attributes with versions in opentelemetry-semconv.
my basic view is that boms are for ensuring version alignment, and there's no need for users to align their SDK and semconv versions
I don't personally find the convenience argument very strong since everyone uses dependabot or renovate to auto-update their dependencies, and so there's not much difference whether you have 1 or 2 places that need to be auto-updated, but of course 100% defer to @jack-berg on the contents of the SDK's bom
and there's no need for users to align their SDK and semconv versions
It's about the API and semconv but its mostly about midset/convenience, wether you need to manage one version (BOM) or many.
one version (BOM) or many
many = 2? (SDK BOM version + stable semconv artifact version?)
or maybe I'm missing something, thanks
I suppose I'm coming from experience of having the semconv libraries as -alpha, and in that case, it really was important to align versions, if you don't want to get some ClassNotFoundException. With the alpha packages, if your semconv dependency gets bumped from what you specified during dependency resolution, then you have a problem. Now that there is a stable semconv available, this shouldn't be a concern. Perhaps my worries are unfounded.
As long as including something like the spring boot BOM doesn't cause my usages of the semconv to have some kind of missing class, then from my perspective it's OK.
That being said, I think the convenience factor is not exactly something to be completely ignored. It's not as simple as a renovate change, at least in my case. If you update spring boot, this updates opentelemetry, what happens to instrumentation version? These are managed in two completely separate places. That's the inconvenience, as it becomes confusing to align all these versions, particularly if you are using instrumentation and you really do actually need to target an SDK version.