Opentelemetry-specification: Change the spec to be closer to OpenTracing

[rochdev]

Right now the specification shares many common traits with OpenTracing, yet it has many differences which I think are unnecessary.

This is problematic for a few reasons:

• One of the goals of this project is to be OpenTracing compatible. The best way to achieve that is to extend OpenTracing. I did some testing on my end and this is definitely possible, at least in JavaScript.
• OpenTracing has a very large user base at this point, and many libraries are implementing it. It will be easier for everyone to switch to OpenTelemetry if all they have to do is to add onto the existing API.
• Several vendors are already OpenTracing implementations or have an OpenTracing compatibility API. A few examples include Zipkin, Jaeger, Lightstep and Datadog.
• It looks like names may have been chosen based on personal opinions. When existing names exist for a domain, these should not be changed without a strong reasoning (i.e. tags vs attributes)

I would like to propose making 2 changes to the specification to allow better interoperability with OpenTracing:

1. Change the naming to be closer to OpenTracing.
2. Make the specification more flexible, which is already being discussed in #165. This will allow OpenTracing to be extended in languages where it's possible.

With these small changes, I believe it would be possible for OpenTelemetry to basically be an implementation of OpenTracing, which will result in easier adoption and migration.

[bogdandrutu]

Same arguments can be made for OpenCensus. Not feasible to make the OpenTelemetry inherit or implement OpenTracing.

[rochdev]

As mentioned above, it is feasible at the very least in JavaScript, so it could be done as a best effort. The same argument cannot be made for OpenCensus since it never gained any traction in the community and most of its use came from Istio. I would also like to point out that in some cases, both OpenTracing and OpenCensus used the same terminology, which reinforces the argument that it should not be changed.

[bogdandrutu]

First of all the user for OpenCensus did not come from Istio, and it had a lot of traction especially with some of the big tech companies.

If there is a specific case where you have a problem with the terminology please file an issue or describe that specific problem.

For "extending" or getting any dependency on OpenTracing that is not possible in this project, as well as it is not possible to depend on OpenCensus.

[bhs]

@rochdev it's unclear whether you're advocating for something Javascript-specific or making a broader push across all languages...

If Javascript-specific: we should strive for consistent OpenTel terminology across languages (per terminology.md)... especially since a software bridge can easily handle redirecting one naming convention to the other.

If across all languages: I don't see why OpenTracing should get a leg up in terms of influencing the OpenTelemetry API. As has been written in many other places, we do want a programmatic adapter/bridge between OpenTelemetry and both OpenTracing and OpenTelemetry, but literally building off / extending of OpenTracing does not seem like the right long-term strategy given the expressed goals for OpenTelemetry.

I'm writing this in a hurry, so apologies if I'm being vague/unclear... happy to try to elaborate.

[yurishkuro]

To add to what Ben said:

• the naming is not arbitrary or based on personal preferences, it was discussed in depth and there are many tickets found in the java repo (perhaps we should move them to specs for better record keeping). There are many conflicting requirements and naming cannot satisfy every one of them. Concretely on tags vs. attributes, both OT and OC had the notion of "tags" with completely different meaning. The decision was made to avoid using "tags" altogether to avoid confusion.
• complete backwards compatibility with OpenTracing API is not the goal of the project, mainly because it's simply not possible given that context propagation is pulled into a lower layer on which tracing, metrics, etc. are dependent.

[rochdev]

but literally building off / extending of OpenTracing does not seem like the right long-term strategy given the expressed goals for OpenTelemetry.

I was not proposing to actually extend OpenTracing but simply to have the same interface. In many languages, interfaces that match are considered equal.

complete backwards compatibility with OpenTracing API is not the goal of the project, mainly because it's simply not possible given that context propagation is pulled into a lower layer on which tracing, metrics, etc. are dependent.

Makes sense. I didn't consider metrics and other telemetry when I attempted to make it work directly with the OpenTracing API. As long as it's compatible in the end, at least it will be easier for users to migrate.

Thanks all for the clarifications!