WIP: Initial Milestones #50
Conversation
tedsuo
changed the title
|
Hi all. Based on feedback, I simplified this doc to just focus on the initial milestones. Please have a look at these milestones. If they look basically good, I would like to merge this so that others can then make PRs and start editing. Cheers! |
|
|
||
| Parity can be defined as the following milestones: | ||
| * A set of interfaces which define the OpenTelemetry Specification in a given programming language. | ||
| * An SDK which can propagate context and record data in common formats. |
There was a problem hiding this comment.
why we are not saying that SDK should satisfy specification? There will be a spec for SDK.
There was a problem hiding this comment.
I feel it is important to make it clear that the interfaces are separate from the SDK, so that it is possible to have more than one implementation. I would like suggestions on how to make requirements such as this clear to everyone.
There was a problem hiding this comment.
I just meant to keep it as separate line, bit instead of saying these two things - context and recording data - just say SDK implementing the specification
There was a problem hiding this comment.
It's a good question! I expect that there are features which we will want to implement in the SDK, but which are not strictly necessary for reaching parity and sunsetting the old projects. So we should to be specific about which SDK features are required to hit our deadlines, vs which could be added later without a problem.
I'm fine with reorganizing the SDK milestones, but that was my thinking.
There was a problem hiding this comment.
propagate context and record data in common format is very vague. Does it include metrics aggregation or it can be left out for instance? Maybe spec needs to have 1.0 requirements subfolder or something. Combined with the common test cases
|
|
||
| ### SDK: Export Common Data Formats | ||
| * Export data in OpenTelemetry format | ||
| * Export data in custom format |
There was a problem hiding this comment.
this also belongs to spec as we need to define two or three "required" OSS backends with the definition on HOW to export there (basically conversion model)
There was a problem hiding this comment.
So again. I'd simply refer to the spec. Saing "support as a minimum things listed in a spec for the release 1.0"
There was a problem hiding this comment.
Ok, sounds good. I like the idea of the spec making it clear what is v1.0.
|
Updated again. If we are mostly okay with the current state, I would like to move this over to the specification repo and commit it, then continue to refine it as the spec evolves. |
| @@ -0,0 +1,68 @@ | |||
| # OpenTelemetry: A Roadmap to Convergence | |||
|
|
|||
| This document covers the intial milestones for each repository developing an implementation of the OpenTelemetry Specification for a specific language. For each new language, we want to quickly achieve parity with existing OpenTracing and OpenCensus implementations. | |||
There was a problem hiding this comment.
| This document covers the intial milestones for each repository developing an implementation of the OpenTelemetry Specification for a specific language. For each new language, we want to quickly achieve parity with existing OpenTracing and OpenCensus implementations. | |
| This document covers the initial milestones for each repository developing an implementation of the OpenTelemetry Specification for a specific language. For each new language, we want to quickly achieve parity with existing OpenTracing and OpenCensus implementations. |
| * Add the milestones listed below to the backlog. | ||
|
|
||
| ## Initial Milestones | ||
| For languages which have both an OpenTracing and OpenCensus implementation, we would like to achieve parity in OpenTelemetry by **September, 2019**, and sunset the existing OpenTracing and OpenCensus ptojects by **November, 2019**. |
There was a problem hiding this comment.
| For languages which have both an OpenTracing and OpenCensus implementation, we would like to achieve parity in OpenTelemetry by **September, 2019**, and sunset the existing OpenTracing and OpenCensus ptojects by **November, 2019**. | |
| For languages which have both an OpenTracing and OpenCensus implementation, we would like to achieve parity in OpenTelemetry by **September, 2019**, and sunset the existing OpenTracing and OpenCensus projects by **November, 2019**. |
| * Utilities to record this data easily | ||
|
|
||
| ### SDK: OpenTracing Bridge | ||
| * The OpenTelemtry SDK implements the latest version of the OpenTracing interface. |
There was a problem hiding this comment.
| * The OpenTelemtry SDK implements the latest version of the OpenTracing interface. | |
| * The OpenTelemetry SDK implements the latest version of the OpenTracing interface. |
| * Interoperability tests using OpenTracing and OpenTelemetry instrumentation together. | ||
|
|
||
| ### SDK: OpenCensus Bridge | ||
| * implement a version of OpenCensus which bridges to OpenTelemetry. |
There was a problem hiding this comment.
| * implement a version of OpenCensus which bridges to OpenTelemetry. | |
| * Implement a version of OpenCensus which bridges to OpenTelemetry. |
|
@tedsuo do you want to use these as github milestones in the client repos? If so it looks like we need milestones for the SDK implementation. |
|
The way it goes now - for the specification and languages adoption I think we will need something like this before september:
And similar thing for SDK adopting these revisions. Without these milestones we cannot get out of the cycle of discussing everything and not closing on issues. |
|
Submitted a separate PR with this one as a starting point. |
This document covers the project setup and initial milestones for language implementations of OpenTelemetry, based on the public roadmap.
See comments in line for open questions.