OpenTracing migration to OpenTelemetry proposal voting

[Pavol Loffay]

Hi,

I would like to make proposals on how we should migrate our OpenTracing specification to the OpenTelemetry project.

The proposal are listed in https://docs.google.com/document/d/1OY4UJodEmjzgY3aX68VafU7xPT7qXdw4YDgnGKhfVd4/edit?usp=sharing. Feel free to comment on the document or ask questions here.

I would like to know your opinion by writing a proposal number with comments in this email thread. 

The biggest question is whether we should allow smooth migration (option #2) from the OpenTracing project to OpenTelemetry or break users in one go (option #1). 

Regards,

[Ken Finnigan]

Thanks for putting forward the options Pavol, as we need to get this discussion going.

I think it is necessary for us to create a new MP project for OpenTelemetry, as opposed to including the new APIs under the existing MP OpenTracing specification as that would lead to confusion. Plus it also goes against the MP notion of failing fast if we need to change direction.

One thought I had is whether it's possible to do some type of "hybrid" of your proposals?

By that I mean within the OpenTracing project as it stands today, switch the specification to use the shim over OpenTelemetry? And then separately work on the new MP OpenTelemetry project.

If we can make MP OpenTracing "compatible" with MP OpenTelemetry, from a given version, it means customers don't need to update existing apps if they're using MP 3.2, as an example, as it uses the OpenTelemetry shim, if they start writing applications against MP 4.0 that uses MP OpenTelemetry. Does that make sense? Am I crazy? About this proposal at any rate.

Ken

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/35668203-9c1a-4afc-88af-9b4f5c5b403d%40googlegroups.com.

[Emily Jiang]

Thank you Pavol for bringing up this for further discussion!

I prefer the option 2:

Proposal #2: Expose OpenTelemetry in MP-OpenTracing specification

With the following reasons:

1. As Pavol mentioned, Open Tracing createed the only annotation @Traced, which has no explicit dependency on any underline tracer implementation. It is still valid and useful for automatic trace propagation. This should still be the case for Open Telemetry.

2. The mission of MicroProfile is to hide the third party libraries, so that end users can stay unchanged or less impacted when the underline implementation has changed. Let's take the example of Hysterix. When Hysterix went to the maintainance mode this year, it has no impact on MicroProfile Fault Tolerance at all. This is what we are trying to demonstrate to our end users that we are open standard. The implementation should deal with the underlined third party libraries, not the end users.

In the case of MicroProfile Open Tracing, it might have a slight impact as Tracer API from Open Tracing (io.opentracing.Tracer) was exposed. I think we should revisit this and should consider to create the API in MicroProfile instead of exposing APIs from the third party libraries in our Spec, e.g. creating a Tracer API in MicroProfile.

3. Having the same specification is nice and straightforward so that there won't have confusion about the spec deprecation and also placing migration on a high priority on the next version of MicroProfile OpenTracing.

Thanks

Emily

[Ken Finnigan]

The problem at present is that MP OpenTracing did expose and expect users to use the APIs of OpenTracing directly, making a switch to OpenTelemetry a breaking change. It's a fine balance, as we don't want to be wrapping every external API just to hide them from MP users, that's a lot of effort for no real benefit.

I disagree that keeping MP OpenTracing as a project and switching it to use OpenTelemetry is in any way straightforward. It would cause confusion that our project is OpenTracing, but it uses OpenTelemetry instead.

Maybe we're better off creating a new project that's just "MP Tracing", to disentangle the MicroProfile project name from whatever the underlying API library might be?

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/4d3f060a-cc32-46d0-b34a-2a096e579b05%40googlegroups.com.

[Stefano Maestri]

On Mon, Oct 7, 2019 at 2:39 PM Ken Finnigan <k...@kenfinnigan.me> wrote:

The problem at present is that MP OpenTracing did expose and expect users to use the APIs of OpenTracing directly, making a switch to OpenTelemetry a breaking change. It's a fine balance, as we don't want to be wrapping every external API just to hide them from MP users, that's a lot of effort for no real benefit.

I disagree that keeping MP OpenTracing as a project and switching it to use OpenTelemetry is in any way straightforward. It would cause confusion that our project is OpenTracing, but it uses OpenTelemetry instead.

I agree 100%

 

Maybe we're better off creating a new project that's just "MP Tracing", to disentangle the MicroProfile project name from whatever the underlying API library might be?

I think it would be a good idea. But let me ask if changing the name w/o wrapping external API (your first sentence) is sufficient to have a real distinction between MP standard and whatever underlying API library. I understand your point above on requiring a lot of effort, but requiring users to use underlying API directly will always create a strong link between spec and impl.

Just my 2C

Best,

S.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe63nBk%2Bm2p1-oBGh%2BV0huoY_2Z4toLymfyUsgmQG2nqyg%40mail.gmail.com.

--

Stefano Maestri

Manager, Principal Software Engineer.

Red Hat

smae...@redhat.com   

[Ken Finnigan]

The MP specification may choose to define some APIs over and above whatever library is being wrapped, but more importantly, it defines how it integrates with other MP specifications

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAMrRDdyEFqc0ma%3DHConGe%3DZLbWzmvTMTjmm6ZWFJ%2BkXJWXjSQg%40mail.gmail.com.

[Alasdair Nottingham]

Hi,

+1 for deprecating MP Open Tracing and creating a new MP Open Telemetry. I think it would be very strange in 2 years time for someone coming in new that we would have something called Open Tracing to interact with Open Telemetry.

Alasdair

> --
> You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAMrRDdyEFqc0ma%3DHConGe%3DZLbWzmvTMTjmm6ZWFJ%2BkXJWXjSQg%40mail.gmail.com.
>

> --
> You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe7wQ5AdmE%2BCRhg1uXShw9WcEc3MmKL30TSPTmrxTASdfg%40mail.gmail.com.

[Stefano Maestri]

Sure, this is what MP spec adds. What I was trying to say is that not wrapping APIs, also the new "MP tracing" will be linked to the underlying library (Open Tracing in this case). This strong link could have its reason, I'm wondering if giving disentangle names is a real benefit for final users.

If I understand you correctly we would have let's say "MP Tracing 1.0" based on OpenTracing requiring users to use (also) OpenTracing underlying API, "PM Tracing 2.0" using OpenTelemetry and its underlying API, "MP Tracing 3.0"  using OpenObservability (or whatever) and its API.

I think it would be more confusing for users than having different projects deprecating the old ones (aka Pavol's #1 Proposal)

Best,

S.   

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe7wQ5AdmE%2BCRhg1uXShw9WcEc3MmKL30TSPTmrxTASdfg%40mail.gmail.com.

[Rudy De Busscher]

Hi,

I would like to see the implementation of Option #2, but the MP 'project' should be called 'MP Tracing'. So that there is no reference to the underlying API.

Rudy

> To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/4d3f060a-cc32-46d0-b34a-2a096e579b05%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe63nBk%2Bm2p1-oBGh%2BV0huoY_2Z4toLymfyUsgmQG2nqyg%40mail.gmail.com.
>
>
> --
> Stefano Maestri
> Manager, Principal Software Engineer.
> Red Hat
> smae...@redhat.com  
>
>
> --
> You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAMrRDdyEFqc0ma%3DHConGe%3DZLbWzmvTMTjmm6ZWFJ%2BkXJWXjSQg%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

[Pavol Loffay]

Thank you all for great comments!

> +1 for deprecating MP Open Tracing and creating a new MP Open Telemetry. I think it would be very strange in 2 years time for someone coming in new that we would have something called Open Tracing to interact with Open Telemetry.

I would not base the decision based on the naming conventions. We can rename the current OpenTracing spec or the artifacts. 

The question really is whether we want to expose two tracing APIs in the same project or create a new project and sunset the current one.

I am adding some more thoughts on proposal #1 Create a new project for OpenTelemetry:

* What would we do with @Traced annotation and other APIs exposed by MP-OT? Just rename packages? 

* The spec for OpenTelemetry would look almost the same as OpenTracing except running a sed command `sed s/OpenTracing/OpenTelemetry/g` :)

Ken had a good idea in his first comment. I was thinking about the same, but there might be some caveats:

* The shim depends on opentelemetry artifacts which expose full opentelemetry API. 

* Supporting two specifications at the same time might be more challenging to test and maintain for implementors.

Personally I am in favor of option #2 or hybrid. #2 It's simpler from the project governance perspective and it provides a clear migration path.

In the hybrid option we could mandate using OpenTracing shim in the specification or make it vendor-specific implementation detail (-1 from my side, we want to maintain better portability and interoperability/migration to OpenTelemetry).

[Ken Finnigan]

On Tue, Oct 8, 2019 at 8:50 AM Pavol Loffay <plo...@redhat.com> wrote:

Thank you all for great comments!

> +1 for deprecating MP Open Tracing and creating a new MP Open Telemetry. I think it would be very strange in 2 years time for someone coming in new that we would have something called Open Tracing to interact with Open Telemetry.

I would not base the decision based on the naming conventions. We can rename the current OpenTracing spec or the artifacts. 

In theory, yes, but it would be a breaking change.

I would prefer an entirely new spec if we're changing the name, to create a clear delineation between each.

The question really is whether we want to expose two tracing APIs in the same project or create a new project and sunset the current one.

I am adding some more thoughts on proposal #1 Create a new project for OpenTelemetry:

* What would we do with @Traced annotation and other APIs exposed by MP-OT? Just rename packages? 

* The spec for OpenTelemetry would look almost the same as OpenTracing except running a sed command `sed s/OpenTracing/OpenTelemetry/g` :)

Ken had a good idea in his first comment. I was thinking about the same, but there might be some caveats:

* The shim depends on opentelemetry artifacts which expose full opentelemetry API. 

Is it not possible to exclude the full API from the shim?

 

* Supporting two specifications at the same time might be more challenging to test and maintain for implementors.

Personally I am in favor of option #2 or hybrid. #2 It's simpler from the project governance perspective and it provides a clear migration path.

In the hybrid option we could mandate using OpenTracing shim in the specification or make it vendor-specific implementation detail (-1 from my side, we want to maintain better portability and interoperability/migration to OpenTelemetry).

My big concern with #2 is the naming. We can't have "MP OpenTracing" using OpenTelemetry, it's just too confusing

 

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/e2853fae-2c21-44e0-b52f-35454247d18c%40googlegroups.com.

[Emily Jiang]

On Tuesday, October 8, 2019 at 2:43:17 PM UTC+1, Ken Finnigan wrote:

On Tue, Oct 8, 2019 at 8:50 AM Pavol Loffay <plo...@redhat.com> wrote:

Thank you all for great comments!

> +1 for deprecating MP Open Tracing and creating a new MP Open Telemetry. I think it would be very strange in 2 years time for someone coming in new that we would have something called Open Tracing to interact with Open Telemetry.

I would not base the decision based on the naming conventions. We can rename the current OpenTracing spec or the artifacts. 

In theory, yes, but it would be a breaking change.

I would prefer an entirely new spec if we're changing the name, to create a clear delineation between each.

Breaking change is guaranteed and makes sense. I prefer to keep the current Tracing spec. By the way, the name MicroProfile OpenTracing could have no relationship to other opentracing.io. I will definitely not call anything near open telemetry. We should stay away from referring the underline technology names.

The question really is whether we want to expose two tracing APIs in the same project or create a new project and sunset the current one.

I am adding some more thoughts on proposal #1 Create a new project for OpenTelemetry:

* What would we do with @Traced annotation and other APIs exposed by MP-OT? Just rename packages? 

* The spec for OpenTelemetry would look almost the same as OpenTracing except running a sed command `sed s/OpenTracing/OpenTelemetry/g` :)

Ken had a good idea in his first comment. I was thinking about the same, but there might be some caveats:

* The shim depends on opentelemetry artifacts which expose full opentelemetry API. 

Is it not possible to exclude the full API from the shim?

 

* Supporting two specifications at the same time might be more challenging to test and maintain for implementors.

Personally I am in favor of option #2 or hybrid. #2 It's simpler from the project governance perspective and it provides a clear migration path.

In the hybrid option we could mandate using OpenTracing shim in the specification or make it vendor-specific implementation detail (-1 from my side, we want to maintain better portability and interoperability/migration to OpenTelemetry).

My big concern with #2 is the naming. We can't have "MP OpenTracing" using OpenTelemetry, it's just too confusing

I think coming up with a new spec causes more confusion, as I think end users have less concern on which underline technology we adopted as long as the trace spans can be joined up and they can view them in Zipkin/Jaeger.

My 2 cents.

Emily

 

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/e2853fae-2c21-44e0-b52f-35454247d18c%40googlegroups.com.

[Ken Finnigan]

On Tue, Oct 8, 2019 at 5:53 PM 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:

On Tuesday, October 8, 2019 at 2:43:17 PM UTC+1, Ken Finnigan wrote:

On Tue, Oct 8, 2019 at 8:50 AM Pavol Loffay <plo...@redhat.com> wrote:

Thank you all for great comments!

> +1 for deprecating MP Open Tracing and creating a new MP Open Telemetry. I think it would be very strange in 2 years time for someone coming in new that we would have something called Open Tracing to interact with Open Telemetry.

I would not base the decision based on the naming conventions. We can rename the current OpenTracing spec or the artifacts. 

In theory, yes, but it would be a breaking change.

I would prefer an entirely new spec if we're changing the name, to create a clear delineation between each.

Breaking change is guaranteed and makes sense. I prefer to keep the current Tracing spec. By the way, the name MicroProfile OpenTracing could have no relationship to other opentracing.io. I will definitely not call anything near open telemetry. We should stay away from referring the underline technology names.

The problem is that by virtue of the name being "MP OpenTracing", it's always been directly associated with OpenTracing.

I don't see there is any way to continue with the current name but completely change the underlying integration. It's just too confusing.

 

The question really is whether we want to expose two tracing APIs in the same project or create a new project and sunset the current one.

I am adding some more thoughts on proposal #1 Create a new project for OpenTelemetry:

* What would we do with @Traced annotation and other APIs exposed by MP-OT? Just rename packages? 

* The spec for OpenTelemetry would look almost the same as OpenTracing except running a sed command `sed s/OpenTracing/OpenTelemetry/g` :)

Ken had a good idea in his first comment. I was thinking about the same, but there might be some caveats:

* The shim depends on opentelemetry artifacts which expose full opentelemetry API. 

Is it not possible to exclude the full API from the shim?

 

* Supporting two specifications at the same time might be more challenging to test and maintain for implementors.

Personally I am in favor of option #2 or hybrid. #2 It's simpler from the project governance perspective and it provides a clear migration path.

In the hybrid option we could mandate using OpenTracing shim in the specification or make it vendor-specific implementation detail (-1 from my side, we want to maintain better portability and interoperability/migration to OpenTelemetry).

My big concern with #2 is the naming. We can't have "MP OpenTracing" using OpenTelemetry, it's just too confusing

I think coming up with a new spec causes more confusion, as I think end users have less concern on which underline technology we adopted as long as the trace spans can be joined up and they can view them in Zipkin/Jaeger.

Can you elaborate on why coming up with a new spec causes confusion? Or at least, more confusion than MP OpenTracing spec integrating with OpenTelemetry?

 

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/7b44fbf1-d919-4b02-818b-5a3a7cc0d18e%40googlegroups.com.

[Alasdair Nottingham]

Ken,

I agree. I think Open Tracing has effectively failed and while OpenTelemetry will support via a shim the open tracing api that seems to be a migration path more than a core ideal.

I think fail fast means that when things happen in the industry we are prepared to ditch things. In this case we should ditch Open Tracing. If we adopt Open Telemetry in a years time no one will understand why they have to use MP Open Tracing to use MP Open Telemetry so I think we should cut our losses as a simplification. I’d cite JAX-WS and JAX-RPC as precedent for this approach.

Alasdair

> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe4z8P2uvitzmA7cqU%2BJUe71yW-bjKH37ZOSxyjOENri4w%40mail.gmail.com.

[Don Bourne]

I prefer the option of ending the MP OpenTracing project and starting a new project:

• OpenTracing seems to be dead.  It appears to just be a shim over top of OpenTelemetry to help OpenTelemetry users migrate.
• The current MP OpenTracing exposes io.opentracing.Tracer and thus is tied to OpenTracing.  The name "MP OpenTracing" also makes a pretty strong association with OpenTracing.
• There doesn't seem to be much reason to keep the same name "MP OpenTracing" and completely change the API (other than the Traced annotation).

I'm not certain we should jump to expose the OpenTelemetry API:

• It's not clear yet that OpenTelemetry's API will be any longer lived than OpenTracing was.  This seems to still be an evolving space.
• If we thought OpenTelemetry (OpenCensus) had tons of active users of their API and was a de facto standard it would make sense to adopt their API -- do we know?

Given most of the value of MP's tracing is in 1) the automatic integration with things like JAX-RS, 2) the linkage with Jaeger/Zipkin, should we focus on that?

• ie. choose one of:
• A. expose no API at all, or at most just expose @Traced
• B. create a minimal tracing API that exposes only what we imagine microservice developers need.
• in either case A or B choose one of:
  
• Take the approach that slf4j / micrometer metrics and others have taken and allow for pluggable implementations
  
• or... Take the approach that MP Metrics / log4j / ... have taken and don't allow pluggable implementations
  

I think we also need to debate what happens to MP Metrics if we adopt OpenTelemetry -- but that might be a separate thread.

Don

> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/7b44fbf1-d919-4b02-818b-5a3a7cc0d18e%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe4z8P2uvitzmA7cqU%2BJUe71yW-bjKH37ZOSxyjOENri4w%40mail.gmail.com.

[Pavol Loffay]

It seems there is a consensus on creating a new project for OpenTelemetry. The new project will provide the same capabilities as the current OpenTracing project.

With the new project creation, we should wait until OpenTelemetry alpha/beta is released to double-check if we can do any integrations with MP metrics.

For the migration or hybrid as Ken calls it :) I propose to update OpenTracing API in MP-OT spec to the latest version 0.33.0 which allows vendors to use OpenTracing SHIM as their OpenTracing tracer implementations.

The benefits are listed here:

* tracer implementations do not backport bug fixes or CVEs for the older version of the API

* other upstream OpenTracing instrumentations moved to the newest versions of the API, so they cannot be used in MicroProfile runtimes

* 0.33.0 allows vendors to OpenTracing SHIM as their tracer implementation - no need to maintain multiple tracers

[Ken Finnigan]

If MP OT updates to OpenTracing 0.33.0, does that require a breaking change release of MP OT?

I recall some previous discussion around this, and I think the answer was yes but I wanted to confirm

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/a4ccd729-e55c-446b-8343-fb3d9112a905%40googlegroups.com.

[Emily Jiang]

I have a few questions on this:

1. How about common code between the new and old Open Tracing spec?

2. Are the issues in the old spec relevant to the new spec?

3. How much exposure do we need to do with Open Telemetry? I will prefer to hide and wrap open telemetry if we can, so that we are less prone to the underline technology changes.

I really hope we are not going to expose Open Telemetry directly and call this new thing MicroProfile Distributed Tracing, if possible.

Thanks

Emily

[Emily Jiang]

I had a typo on my first question. It should read:

How much common code between the new and old Open Tracing spec?

Emily

[Pavol Loffay]

> If MP OT updates to OpenTracing 0.33.0, does that require a breaking change release of MP OT?

Yes it will be a breaking change release.

The new project for OpenTelemetry would provide the same features as current MicroProfile-OpentTracing. Therefore the specifications would be almost the same ('s/OpenTracing/OpenTelemetry/g' and a couple of additions and removals related to use of SDK).

The TCK and API modules would be refactored to a different package and it would use OpenTelemetry APIs instead of OpenTracing.

@Emily 

> I really hope we are not going to expose Open Telemetry directly and call this new thing MicroProfile Distributed Tracing, if possible.

Most people expressed negative on creating a separate tracing API just for MicroProfile. I think we could certainly introduce more annotations/apis to avoid using OpenTelemetry directly. On the other hand we should be as much compatible as possible to allow users to use other upstream instrumentations in their projects.

[Tobias Stadler]

Hi,

I would like to see an OpenTracing Release using OpenTracing 0.33.0 and a new spec project supporting OpenTelemetry.

Regards Tobias

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/7b849677-78a5-4ef2-8ce3-41b2ee5f2d2b%40googlegroups.com.

[Alex Lewis]

Hi,

I agree with Tobias regarding a release against OpenTracing 0.33.0 as OpenTelemetry is still some time away.

Rather than build a new spec that is closely related to OpenTelemetry but is somehow also different to protect MP users, I wonder whether this is an opportunity to take a step back.

Maybe we could consider a MicroProfile Observability spec, covering Metrics, Tracing and Logging? The focus of this spec would be on the fast adoption/instrumentation of applications rather than the exact mechanics exposed by the OpenTelemetry API/Impl.

For instance, more recently in the mp-logging thread I started a point about the usefulness of the MDC came up. Maybe, instead of apps having to manually add items to the MDC, we could annotate object members with @Observed (or equivalent), which would mean it was automatically captured as part of a processing operation (not necessarily a thread). Similarly for "tracing", methods that are the "start"  of the same "process/task" could be annotated with @ObservableProcess(name), where the name collects those processing threads together. Finally, a Logging API and spec that means that log statements that are part of a process being tracked by @ObservableProcess(name) would have a correlation ID attached to them to tie them back to the overall process and the member variables annotated by @Observed would be available for logging messages or included in a serialized JSON log object.

Cheers

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/7b849677-78a5-4ef2-8ce3-41b2ee5f2d2b%40googlegroups.com.

[Pavol Loffay]

It seems there is an agreement to upgrade OpenTracing dependency to version 0.33.0 and release MP-OpenTracing 2.0. 

Then the question is whether OpenTracing 2.0 should be included in MicroProfile umbrella release 3.3 in February 2020 or not. 

I spoke to Felix Wong and he would like to make it optional so it would not be included in the umbrella artifact and runtimes would override it if they are willing to upgrade it. 

By doing this I am not sure if a runtime can be classified as  MP compatible if it overrides one of the artifacts from the umbrella release which also happens to be a breaking change release.

For better portability I would advocate the 2.0 release should be included in the umbrella release. All tracer implementation have already moved to 0.33.0 a long time ago the runtimes just have to pull in a newer release of the tracer, it's not much work required.

On Wednesday, October 23, 2019 at 12:18:38 PM UTC+2, Alex Lewis wrote:

Hi,

I agree with Tobias regarding a release against OpenTracing 0.33.0 as OpenTelemetry is still some time away.

Rather than build a new spec that is closely related to OpenTelemetry but is somehow also different to protect MP users, I wonder whether this is an opportunity to take a step back.

Maybe we could consider a MicroProfile Observability spec, covering Metrics, Tracing and Logging? The focus of this spec would be on the fast adoption/instrumentation of applications rather than the exact mechanics exposed by the OpenTelemetry API/Impl.

These are all valid points. We should definitely consider doing so, at least minimize the exposure of the 3rd party dependencies if we decide to go with a similar approach as in OT spec.

One thing to bear in mind is that we should provide interoperability with OTEL to allow users to pull in any OTEL instrumentation. OTEL will provide a large ecosystem of instrumentations it does not make sense to reinstrument with our own APIs.

[Alasdair Nottingham]

It can’t go into a 3.3 umbrella release because you have a breaking change. It would force the umbrella to go to 4.0 which we agreed last year wouldn’t happen until June.  

I think if we are going to do anything in a major release I’d suggest removing open tracing so it becomes a true stand alone spec. 

Alasdair Nottingham

On Nov 14, 2019, at 5:21 AM, Pavol Loffay <plo...@redhat.com> wrote:



To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/509c5f3e-f84b-43ff-9695-aa6b296aa98d%40googlegroups.com.

[Kevin Sutter]

Or, we could do the breaking change in OpenTracing 2.0 and leave that as a standalone Spec (not part of the Platform).  Since we're looking to go to OpenTelemetry soon and the only reason for this OpenTracing 2.0 (with opentracing.io 0.33 API) is to provide the bridge/shim to OpenTelemetry, let's just leave this version out of the Platform.  Our definition for the Platform contents states that we don't have to automatically pick up new releases.  It's up to the Platform to determine applicable Component versions.:

• The umbrella specification ultimately chooses which component spec versions to include. e.g. the umbrella specification may decide to remain at an older component spec version.

-- Kevin

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

[Emily Jiang]

+1!

Further to what Kevin has said, MP Open Tracing needs to release 1.4 to adopt Jakarta EE8, which should be included by MP 3.3.

Then MP Open Tracing release 2.0 with opentrace.io 0.33 API but this version will not be included by MP 3.3.

If we release MP 4.0 in June, I think we should add MP Open Tracing 2.0 as this one should be in umbrella release before Open Telemetry is adopted and released by MP.

Thanks

Emily

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/509c5f3e-f84b-43ff-9695-aa6b296aa98d%40googlegroups.com.

[Ken Finnigan]

For MP 4.0 in June, isn't it better to remove OpenTracing 1.4 from the platform, which is a breaking change? And leave OpenTracing 2.0 as standalone that implementations can include if they want.

Then OpenTelemetry, or whatever we call it, could be added back into the platform at any subsequent release as it's then additive as opposed to a backward breaking change?

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/31cc4c24-00b9-49c4-974c-feda7fd0de3b%40googlegroups.com.

[Ladislav Thon]

pá 15. 11. 2019 v 17:40 odesílatel Ken Finnigan <k...@kenfinnigan.me> napsal:

For MP 4.0 in June, isn't it better to remove OpenTracing 1.4 from the platform, which is a breaking change? And leave OpenTracing 2.0 as standalone that implementations can include if they want.

Then OpenTelemetry, or whatever we call it, could be added back into the platform at any subsequent release as it's then additive as opposed to a backward breaking change?

I like this idea very much, as it reduces the number of breaking changes as much as possible (down to 1), and gives implementors considerable freedom in how to deal with the situation.

LT 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe61qMUs7JQ2cn%2Bnx8%2BLKQy9as_7bLkD86KYjPyXN0tTcg%40mail.gmail.com.

[Alasdair Nottingham]

+1

As per my earlier email I think we should use the 4.0 release as an opportunity to prune what is effectively dead technology and then in a future release we can add Open Telemetry.

> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CALbocOmqBF02QKZkEyU8n8-Pa5%2BfWTApRHwsrMuvTmE%3D-DoUxg%40mail.gmail.com.

[Emily Jiang]

For MP 4.0 in June, isn't it better to remove OpenTracing 1.4 from the platform, which is a breaking change? And leave OpenTracing 2.0 as standalone that implementations can include if they want.

When end users moves to MP 4.0, they have to include MP OT separately if we remove OT from the platform. Personally, I think we should have this feature in umbrella release till MP Open Telemetry or something like that is available to fill the place. I am not sure what gain we are having by removing the feature from MP 4.0 without providing anything alternative.

My 2cents.

Perhaps someone who uses MP OT should chip in.

Emily

You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/unYFj9EpTgM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe61qMUs7JQ2cn%2Bnx8%2BLKQy9as_7bLkD86KYjPyXN0tTcg%40mail.gmail.com.

--

Thanks
Emily

[Ken Finnigan]

Not necessarily, it depends on what any given runtime chooses to do. Most runtimes may choose to include the new OpenTracing 2.0 even though it's not part of the platform, essentially meaning no change from a user perspective.

Removing it on the next breaking change frees us from waiting for the next breaking change to include a replacement. It's far more flexible, while still offering runtimes the ability to mitigate it's removal by them including it directly.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAECq3A-A8AoYOG7L0WHd0mXwrV%2BnJzictL6W%3DXt5mf5ZeNA_EQ%40mail.gmail.com.

[Alasdair Nottingham]

I agree. I don’t see a huge amount of use of MP Open Tracing in the wild and I think that the Open Telemetry change is going to put a brake on new people adopting it. So I’d much prefer to position ourselves now for a post Open Tracing world. I think it’ll make MicroProfile look somewhat backward for mandating a superseded technology.

Alasdair

> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe7n%3D73yKVjB4FwYCi3ExNS-n2Z57iMfA4NCp5f2%3D2TzVQ%40mail.gmail.com.

[Kito Mann]

+1

I've seen this confusing already for a client that's not using MicroProfile. Avoiding shifting implementation details is one of the key benefits of standards.

___

Kito D. Mann | @kito99 | Java Champion | Google Developer Expert | LinkedIn

Expert training and consulting: PrimeFaces, PrimeNG, JSF, Java EE, Polymer, Web Components, Angular

Virtua, Inc. | virtua.tech 

+1 203-998-0403

* Listen to the Enterprise Java Newscast: http://enterprisejavanews.com

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CDBEB042-E2EC-451C-A218-90D22BE07564%40gmail.com.

[Sean Scott]

Hi Pavol,

Can you quantify the breaking the changes?  Is the issue that the implementors of of the MP spec will have to add support for some new capabilities? 

Or is it that consumers of the spec will be broken by API removal or API modifications ? 

Thanks!

-sean