In general, everywhere we use static registration (filters, stats sinks, loggers, tracers, etc.) it would not be difficult to also support dynamic loading. While some set of people want everything to be statically linked, others want dynamic loading flexibility. I have no objection to adding optional dynamic loading support if someone wants to take on this project.
mattklein123
All 6 comments
Please can we define (either here or in a separate issue) in what circumstances it would be necessary to recompile loadable modules?
For example, envoy could apply semantic versioning:
- loadable modules would need recompiling for distinct major versions of envoy,
- loadable modules could be reused without recompilation between versions of envoy with the same major version.
glyn
on 22 May 2018
Without a large amount of work on ensuring binary compatibility of all the infrastructure that a module could depend on, my guess is that we would require modules to be compiled from the exact same source as the envoy that will load them.
ggreenway
on 22 May 2018
I agree with @ggreenway until https://github.com/envoyproxy/envoy/issues/3390 is solved, which if I'm being realistic is probably 1-2 years out.
mattklein123
on 22 May 2018
Thanks. That's a clear definition. ;-)
glyn
on 22 May 2018
I would think that you could have a generic http filter and network filter in which you specify what .so file to load and there you would call a predefined method - proxying the call to the dynamic .so file - passing as parameters - callback functions to be invoked for logging, setting meta variables or some other process in which you would do the logic in your dynamic .so file but logging and other envoy stuff would be delegated to the native implementation of the network / http filter.
Thoughts on this?
atrifan
on 19 Jun 2019
Thoughts on this?
My preference is to actually support it more directly in the code at each extension point. Meaning, today we statically register all extension points and then search for them at load time by name. I think what we need to do is actually allow extensions to optionally be specified by an .so/.dll, and then just load that.
mattklein123
on 19 Jun 2019
Related issues
roelfdutoit
路
3Comments
lps0535
路
3Comments
zanes2016
路
3Comments
hzxuzhonghu
路
3Comments
alkov-ibm
路
3Comments
Most helpful comment
My preference is to actually support it more directly in the code at each extension point. Meaning, today we statically register all extension points and then search for them at load time by name. I think what we need to do is actually allow extensions to optionally be specified by an .so/.dll, and then just load that.