OpenTelemetry Monthly Update: July 2019

Welcome to the first monthly OpenTelemetry community update! Every month we’ll be posting an update in the days following the monthly community meeting, and each will include a summary of the latest news and activities from across the project. These include:

• Status updates from every Special Interest Group (SIG)
• News from the Governance and Technical committees
• Demos of new functionality
• Updates on upcoming conference talks, user meetings, or blog posts
• Any other items or discussions of note to the broader community

For those who haven’t met me, I’m Morgan McLean (@mtwo on GitHub), the product manager for OpenTelemetry at Google and part of the founding team for OpenCensus. We’ll likely rotate through different authors in future community updates and new authors will introduce themselves in each one.

Community Communications

Community Meetings

If you’re not already attending the monthly community meetings, we definitely recommend joining. These meetings take place over Hangouts on the second Wednesday of each month and alternate between 10:00 AM PST and 4:00 PM PST. They’re listed on the OpenTelemetry community calendar (web, gCal, iCal), and we’ve invited the community, contributors, and technical committee mailing lists, meaning that members of these lists should have the community meeting automatically shown on their calendars.

We maintain agendas and notes from past meetings in a shared Google doc, which is also listed in the calendar invites for each meeting.

Mailing Lists

Speaking of mailing lists, we now have several. The full set is detailed on the community GitHub page, and we recommend joining the community list if you haven’t already.

Slack vs. Gitter

We recently held a poll to determine the community’s preferences for the instant messaging platform that members want to use. Slack received roughly 60% of the votes, Gitter 28%, and other options filled in the remaining 12%.

The governance board has since explored the costs and benefits of Slack and Gitter. With Slack we had a few different options available: we could pay a license fee for each user, use a free instance with a bot that archives old conversations, or create channels on the existing CNCF Slack instance. However, all of these options have significant drawbacks: nobody is willing to sponsor the cost of a paid instance, an investigation into auto-archiving bots showed that they’re either non-functional or not designed for our use case, and sharing a busy Slack workspace with the rest of the CNCF didn’t appeal to anyone.

Thus, the decision has been made to go with Gitter, on the existing OpenTelemetry instance. We’ll be shutting down the existing Slack organization shortly and we’ll redirect existing users to Gitter. You can read more about the decision criteria in this issue update.

Project Schedule

As discussed during the project’s first announcement, we are still aiming to release usable versions of the OpenTelemetry libraries for Java, Go, Node, Python, and .Net by September, followed by production-ready releases in time for Kubecon San Diego in late November. The overall project milestone list is maintained in the specification repository on GitHub.

Backwards compatibility with existing OpenCensus and OpenTracing instrumentation will be made available in the late November release.

SIG Updates

All major project workstreams, including the main specification, libraries for each language, agent / collector functionality, and automatic instrumentation are run by a special interest group, or SIG. You can find a complete list of all OpenTelemetry SIGs on the community GitHub page. We go over the latest news from each SIG during the monthly community meetings, and these updates are then written into the monthly community update (this post).

Specification

• Merging similar GitHub issues together in order to maintain a single discussion for each topic. Issues are also being triaged and assigned to project milestones.
• Work is on track for the September / November release milestones.
• The initial specification ws based on the Java API. We are reworking it to be more language neutral, focusing more on the requirements and less on how they are implemented.
• Adding more high-level documentation about the project.

.Net

• Progress has been slower than expected due to several of the members being on vacation or having unexpected work travel, however work is close to completion

Go

• The Go SIG is looking to recruit additional committers and maintainers. If you know anyone who is proficient at Go and is interested in the observability space, please put them in touch with Rahul (@rahulpa on GitHub).
• The tracing SDK is currently being ported from the OpenCensus implementation, and both the SDK and API are expected to be functional by the end of the month

Java

• The SDK is almost complete, with metrics being blocked by an outstanding RFC
• The next snapshot release will be tested against an existing OpenCensus project, and is expected to replace half of the existing implementation’s functionality

Javascript

• The tracing, resource, and context APIs are now complete
• Work is underway on the basic tracer and scope manager SDKs, and these will be completed by the end of July

Python

• Work on the tracing API is underway and will be complete by the end of July. Development on the tracing SDK will commence once this is complete.

Ruby

• The tracing, resource and metrics APIs have been prototyped with no-op implementations
• Work is underway on the test suite and the distributed context API

Agent / Collector

• The first version of the agent and collector ported from OpenCensus now works and already supports all existing receivers. The testbed has also been successfully ported over.
• Processors are being migrated from OpenCensus

Automatic Instrumentation (RFC)

• Requirements for automatic instrumentation are now available in the RFC repository. Auto-instrumentation implementations will be language specific; the Ruby SIG already has a proposal for automatic instrumentation here.
• A second RFC is discussing minimal code-change “greybox” instrumentation and whether this should be in the scope of the first RFC