Update for MP Telemetry 2.1

[jasondlee]

Update MP Reactive Messaging for compliance/integration with MP Tel 2.1

Bump version numbers
Fix semantic convention issues

[jasondlee]

FTR: after integrating this update into my local WF build -- and making some WF module changes to pick up the "incubating" semconv jars -- the failing tests in the MP 7.1 topic branch pass.

[cescoffier]

@brunobat FYI - are we using the same version in Quarkus

@jasondlee what do you mean by "fix semantic conventions"? Did they change? Are we breaking dashboards?

[brunobat]

Quarkus is still on MP Telemetry 2.0. No timeline to upgrade yet.

[brunobat]

Created this: quarkusio/quarkus#48594

[cescoffier]

Hum, so we cannot really update - we would need 2 branches...

[jasondlee]

@brunobat FYI - are we using the same version in Quarkus

@jasondlee what do you mean by "fix semantic conventions"? Did they change? Are we breaking dashboards?

Two things: the codebase was reorganized in newer versions of io.opentelemetry.semconv:opentelemetry-semconv, so, in upgrading, there we compilation failures. Those are easy to fix and invisible to the end users. Additionally, there were deprecations for some attribute names, but those can be ignored relatively safely for now if we choose to do so. Some names, though, were changed (e.g., messaging.client_id -> messaging.client.id) or just completely removed. For those, dashboards could very well break. I'm not sure we have a good solution for that. It's an issue that we've had to face (and, I think, accept) in WF/EAP as our options seem to be breaking dashboards as we upgrade, or try to maintain some sort of compile-/run-time compatibility layer. The conventions have finally hit a certain level of stability, so breakage moving forward should be minimal, but, as you can see in the diff, some attribute names are from io.opentelemetry.semconv:opentelemetry-semconv-incubating, which means they very well may change in future releases.

[jasondlee]

Hum, so we cannot really update - we would need 2 branches...

How that's handled here I'll leave to those familiar with the project. The only reason I created this PR is because we were hoping to get MP 7.1 into WF 37 and there were test failures for otel+kafka, but the "owner" on the WF is out of the office, so I made a best effort attempt to capture something that would work, with the idea that it would be cleaned up as necessary by those more familiar with the project. As a consumer downstream, I have no real opinion on how the changes should be handle here, so I happily defer, but remain willing to assist as needed.

[cescoffier]

It would be great to avoid having to maintain two branches (one for quarkus and one for WildFly).
If we update, we risk breaking Quarkus, so we need to coordinate to ensure a safe update. It would also require a new minor, as we would not backport this to Quarkus LTS.

[jasondlee]

Completely agree. It doesn't look like this will make WF 37, so we have time to coordinate with the Quarkus team.

[brunobat]

@cescoffier what would be the perfect timing, after next LTS or just before, so it's available there?

[cescoffier]

@brunobat, we should either consider it now (or by the beginning of July at the latest) or mid-August after the LTS feature freeze.

[jasondlee]

@brunobat, we should either consider it now (or by the beginning of July at the latest) or mid-August after the LTS feature freeze.

@cescoffier Do you have an update on the timeline for this?

[brunobat]

Back from PTO. Will know more about the timeline soon.

[jasondlee]

Back from PTO. Will know more about the timeline soon.

@brunobat I've updated my PR based on main. Any update on a timeline?

[brunobat]

Back from PTO. Will know more about the timeline soon.

@brunobat I've updated my PR based on main. Any update on a timeline?

Not before the end of next week.

[jasondlee]

Back from PTO. Will know more about the timeline soon.

@brunobat I've updated my PR based on main. Any update on a timeline?

Not before the end of next week.

We'd really like to get this into WildFly 38, for which the feature freeze is rapidly approaching, so the sooner this can be finished the better for us...

[ozangunalp]

rebased on the last fixes on the main

[ozangunalp]

I was about to merge this, but the fact that existing dashboards will break after this bump is a bit concerning.

@jasondlee Do you think we should also include old otel-semver attributes in the spans?

[ozangunalp]

Do you think we should also include old otel-semver attributes in the spans?

@brunobat I'd like to have your opinion on this.

[brunobat]

Do you think we should also include old otel-semver attributes in the spans?

@brunobat I'd like to have your opinion on this.

Not much we can do because they do this type of think frequently. We need to issue the changes in the release notes.

[ozangunalp]

Ok thanks! Fine by me then.

[jasondlee]

Do you think we should also include old otel-semver attributes in the spans?

@brunobat I'd like to have your opinion on this.

Not much we can do because they do this type of think frequently. We need to issue the changes in the release notes.

We've struggled with this in WildFly as well, but there's little practical that can be done. I think most of what changes is considered alpha status, so that should be expected, with most of the attributes being stable, if that helps any. Short of forking the project and putting a lot of work into maintaining those old attributes, I think this is sadly one of those facts-of-life issues with OpenTelemetry.

[brunobat]

Messaging semantic conventions are still incubating and we should move on as they break things, @ozangunalp. We need to document all the changes, though.