OpenTelemetry Monthly Update: February 2020
Welcome to the last community update before the first OpenTelemetry components enter beta!
In this month’s update, we’ll discuss rapid progress that we’re making towards the first beta release, plans for the beta announcement, a decision about where to store non-core code for things like integrations and exporters, and the OpenTelemetry registry. We’re skipping individual SIG updates this month.
Beta Development
For more details, see the Beta launch plan and our previous blog post on the subject.
The Java, Go, Python, JavaScript, and Collector SIGs are progressing rapidly towards the first beta release on March 16th (next Monday). While this is a significant milestone for these SIGs and the OpenTelemetry project as a whole, it represents the beginning of the beta period, which will see a wave of beta releases across these SIGs and others.
At a minimum, each of the Java, Go, Python, and JavaScript SIGs will produce a 0.3 beta release (some already have) followed by another beta release that implements version 0.4 of the specification. Most SIGs will also offer additional releases during the beta period that include bug fixes, optimizations, additional functionality, etc.
The Java, Go, Python, JavaScript, and Collector SIGs are all on track to have code and documentation ready for the March 16th target date. The .Net SDK will enter beta at a later date, along with other SIGs as they are ready. A few components are coming in hot, particularly the implementation of resource identifiers and context propagation and sampling-related changes.
As each SIG proceeds through the beta period, we will begin making plans for the release candidate phase, followed by GA releases.
Beta Announcement
With Kubecon EU postponed we’re still formulating an announcement plan. The current thinking is that the official beta announcement will take place in the weeks following the first code drop, on a similar schedule to the original Kubecon plan (March 30th), however none of this is final yet. While we want to make some noise with the beta announcement, we’re also cognizant that this is the first functional release and we don’t want to set expectations unreasonably high. We’ll save our firepower for the GA announcement.
I’ve scheduled 90 minutes for stakeholders (SIG maintainers and the beta crew) on Monday to review the Node, Java, JavaScript, Go, and Collector releases and to start planning the announcement. This meeting is on the public calendar, so please join us at 12:30 PT if this is a topic that is relevant to you.
Non-core code
Over the past month, we’ve had inquiries from maintainers and contributors about where OpenTelemetry-related code like integrations, exporters, add-ins, etc. should be stored, if they’re not clearly attached to a different organization (for example, many integrations and exporters will be maintained within vendor-specific organizations).
The new official guidance on this is that each SIG should manage non-core code through additional repositories inside of the open-telemetry GitHub organization. This ensures that shared code abides by the same licensing policies as the rest of the OpenTelemetry project, which is necessary for many organizations that use and contribute to the project.
Registry
Ted and Austin have created a registry of OpenTelemetry components, which includes everything from the core language-specific APIs + SDKs, to the collector, integrations, exporters, and other components. This is open, community supported registry so please add more components as you find or create them! Registry entries can point to code contained within the open-telemetry GitHub organization or elsewhere.
