Tracking Issue for Dynamic Modules

[mathetake]

I will dedicate this is the tracking issue for the dynamic module feature. The description here will be updated as we make progress.
This issue will serve as a central place for tracking the progress as well as the feature requests, etc.

General Status

The minimal version has been merged and available on the main branch to be released in 1.34 in April 2025.

• The high-level documentation is here.
• The example repository: envoyproxy/envoy-dynamic-module-example
• Basic functionality such as header manipulation, body manipulation, local reply, and dynamic metadata are available.

P0 (Before v1.34)

• (@mathetake) Add "remove header" callbacks. dynamic_modules: adds support for header removal #38432
  • I think making set_xxx_header/trailer callbacks accept null pointer indicating removal would be simpler'
• (@mathetake) Initial support for attributes dynamic_modules: initial support for attributes #38519
• (@mathetake) Remove "WIP" from the config API.
  • This will be by the end of next March.

P1 (nice to have in v1.34)

• (help wanted) Add a minimal test target here to ensure the linking work on macos. My attempt: build: make dynamic modules work on macos #38437
  • As indicated in chore: fix build on m1 mac #38363, macos linker doesn't support --export-dynamic so I suspect that the loading is not working right now. Since we are not running tests at all right now, I would like to add //test/extensions/dynamic_modules/http:filter_test there and fix the linker stuff accordingly.
• (@mathetake) Build a foundational asynchronous callback mechanism for dynamic modules.
  • Proper life cycle management via something like a manual reference counting callback would be needed to provide the safe interface.
    • This would affect the design of SDK as well, so we need to resolve this before we work on another language SDK.
• Callout related ABI.
• (help wanted) Add stats/metrics callbacks to allow dynamic modules to emit metrics.

Other outstanding items / Open questions

• Upstream HTTP filter support: Upstream HTTP Filter Support for Dynamic Modules #38448
• Network filter support
• Other language SDKs (Notably, C, C++ or Zig, maybe Go.)
  • This will be revisited after we have a good enough asynchronous callback mechanism.
  • Do we ever need/want to support other languages than Rust?
• After all the feature requests settle down, revisit the compatibility requirement and maybe relax it to work across multiple versions of Envoy.

[mathetake]

cc @bplotnick @thenewwazoo

[isker]

This might be unnecessary if we can provide a good enough asynchronous callback mechanism since dynamic modules can do whatever they want in the module including making outbound HTTP requests, etc.

Do you mean that in this situation, dynamic modules would be using arbitrary HTTP clients? We use proxy-wasm filters today to make outbound HTTP requests, and it's nice that those use Envoy clusters, because they get the same configuration, connection pooling, service discovery, statistics, etc that the rest of Envoy has.

[mathetake]

yeah i guess that makes sense - thank you for clarifying @isker. Let's add the envoy-managed callouts just like Lua and Wasm

[nfuden]

As part of P1 or P2 is there any desire to make a per route message for this filter?

I've been playing around with the filter and would love to be able to get its configuration a bit more granular.
If it fits roadmap happy to spend some time to see if i can throw up something for it.

[mathetake]

yeah sure, indeed i expected that someone will request for it. happy to review!