proposal: design Wasm ABI for tracing providers

[yskopets]

Title: design Wasm ABI for tracers

Context:

• after Envoy moved to libc++, dynamic_ot-based tracers got broken because they were relying on C++ ABI
• following that, a potential new tracing provider expressed its interest in C ABI instead
• so, it seems that tracing providers could benefit from having their own Wasm ABI

Proposal:

• Let's try to design Wasm ABI for tracers
• Along the way, let's expand on ideas that came out of reviews for Wasm upstreaming PRs, namely:
  • ABI should be modular and complementary to proxy-wasm/spec
  • ABI should use versioning scheme similar to regular Envoy extensions, e.g. envoy.tracers.v1alpha0
  • ABI should support usage model consistent with regular Envoy extensions, e.g. it should be possible to have N instances of the same extension type each with a different configuration
  • ABI should be optimized for data passing from Envoy to the Wasm extension in just 1 function call

[htuch]

@yskopets do you have any thoughts on how existing trace libraries will work under Wasm? Is it reasonable to suspect that most of them will "just work" when built for a Wasm target and wrapped with an Envoy Wasm tracing ABI shim?

[mattklein123]

Is it reasonable to suspect that most of them will "just work" when built for a Wasm target and wrapped with an Envoy Wasm tracing ABI shim?

This would be optimal though I'm skeptical it's going to be easy to make this work. At a high level I think it's a great idea to start working on other extension types and see how we can make that work, especially as we navigate the envoy specific vs. non-envoy specific ABI.

My suggestion would be to start as @yskopets suggests and let's do a design proposal for an Envoy WASM tracing plugin ABI, and let's figure out where the process/design holes are. cc @jplevyak @PiotrSikora

[yskopets]

@htuch

Right now, Envoy has roughly 3 categories of tracers:

1. Envoy-agnostic (dynamic_ot)
2. Almost Envoy-agnostic (opencensus)
3. Envoy-native (datadog, lightstep, xray, zipkin)

So,

1. Envoy-agnostic tracers should "just work".
2. Almost Envoy-agnostic - opencensus - hard to say. OpenCensus is very unique.
3. Envoy-native tracers will definitely require some changes:
   • TLS logic should be completely removed from the tracer
   • it would be necessary for Envoy to expose to a Wasm extension parts of API like ClusterManager, Runtime::Loader, etc. So, it might be more reasonable to slightly redesign the tracer instead.