Generalize concrete implementation registration and lookup. #967
Comments
|
Do we want to call this static registration to distinguish from fully dynamic registration (e.g. using ELF loadable objects?). |
|
I'm name agnostic. We could even just call it "registration". |
|
+1 to this, and also doing the bazel work to make it easy to compile things in and out. The static registration can be modeled after the existing filter stuff. |
|
Should we use reverse DNS naming notation? Also see https://github.com/lyft/envoy-api/issues/34. |
|
Works for me. Slightly more crazy: we could have a single registry for all of this stuff to make it readily extensible to new classes of things. However, retrieval probably ends up involving a static_cast which makes me a bit uncomfortable. |
|
I think you mean |
Added a static registration mechanism (following the pattern of filters mentioned in the comments on #967) for http tracers. This will likely be expanded to a more general registration mechanism in future work. This PR is part of the work towards solving #967. This commit deprecates the existing HttpFilterConfigFactory filter API in favor of NamedHttpFilterConfigFactory.
|
@tschroed I'm going to close this as done. I think we have general agreement on approach here. We can add new registration for things like stats as needed. |
This is part of a larger effort to make various implementations more flexible by allowing proprietary components to be statically registered with Envoy needing only to be linked to the binary at build time and configured at runtime #967 . The user-visible configuration changes do involve a few deprecations: statsd_udp_ip_address and statsd_tcp_cluster_name will be deprecated, and their equivalents will be moved to a new stats_sinks array where the configurations for any statically registered sink will exist. As a part of this change, all integration tests were moved to the new configuration format, but a new configuration test was added to ensure that the deprecated format continues to work until it is removed in 1.5.0.
Automatic merge from submit-queue. Extract the subject field of a JWT Extract the subject field (i.e., sub) of a JWT, which is used during the authentication. To run the tests: bazel test //src/envoy/auth:jwt_test **What this PR does / why we need it**: Extract the subject field (i.e., sub) of a JWT, which is used during the authentication. **Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes envoyproxy#966 **Special notes for your reviewer**: **Release note**: ```release-note ```
Description: Changes filter instantiation to be a per-stream basis, across the core, bridge, and iOS platform layers. Also improves usage of CFBridge* functions to be better in line with their intent. Risk Level: Moderate Testing: Local end-to-end Signed-off-by: Mike Schore <[email protected]> Signed-off-by: JP Simard <[email protected]>
Description: Changes filter instantiation to be a per-stream basis, across the core, bridge, and iOS platform layers. Also improves usage of CFBridge* functions to be better in line with their intent. Risk Level: Moderate Testing: Local end-to-end Signed-off-by: Mike Schore <[email protected]> Signed-off-by: JP Simard <[email protected]>
Tracing, stats, and logging should have dynamic registration for runtime lookup of specific implementations.
For example, right now there is a lightstep and a zipkin tracing implementation. These are selected using config values and if/else in MainImpl::initializeTracers.
Sometimes it's undesirable to even attempt to link against specific implementations. For example, Lightstep introduces a symbol collision with existing google3 code which we want to link in.
Instead we should have a dynamic registration mechanism similar to RegisterNetworkFilterConfigFactory that allows us to selectively link in dependencies.
The text was updated successfully, but these errors were encountered: