Takeshi Yoneda
Takeshi Yoneda
FYI: Dynamic modules [require the exact version match (at least for now)](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/advanced/dynamic_modules#compatibility), so for example, the modules working with Envoy v1.50.0 are not guaranteed to work with v1.51.0 (if the...
There's no mechanism to check that without actually loading Envoy. Like i suggested, the current best way is to tie the Envoy container with modules as in [the examples](https://github.com/envoyproxy/dynamic-modules-examples/blob/main/Dockerfile) or...
so i think we can go with this as-is leaving the lifecycle of dynamic modules to users for now, and then we can later add the "managed" installation of remote...
> but any guesstimate on average and max sizes of the module ? shared library is almost the same as normal application binary, so the question would be how large...
So *currently* a dynamic module's capability is as same as Lua and Wasm so I don't have that concern right now. However yes indeed it can expand to have more...
I feel like this should be done in an API field validation rather than trying to handle at the formatter implementation. like for example reject if a curly bracket is...
Verify Examples job failure is irrelevant to this eg the same error on main https://github.com/envoyproxy/envoy/actions/runs/9708036595/job/26794181496
thanks @RyanTheOptimist, added an integration test with access logger in https://github.com/envoyproxy/envoy/pull/34958/commits/747b64282442575299f39e4f53e7848f7f5832a3
@RyanTheOptimist this formatter is an extension so that would require using `envoy_extension_cc_test` for say tcp_proxy_integration_test. Is that acceptable practice in general? (I am not knowledgeable on the extension visibility policy)...