factory context: refactored factory context#31189
Conversation
Signed-off-by: wbpcode <wbphub@live.com>
Signed-off-by: wbpcode <wbphub@live.com>
wbpcode
requested review from
RyanTheOptimist,
alyssawilk,
kyessenov and
mattklein123
as code owners
Signed-off-by: wbpcode <wbphub@live.com>
Signed-off-by: wbpcode <wbphub@live.com>
Signed-off-by: wbpcode <wbphub@live.com>
Signed-off-by: wbpcode <wbphub@live.com>
|
/wait on main merge (sorry!) |
Signed-off-by: wbpcode <wbphub@live.com>
Signed-off-by: wbpcode <wbphub@live.com>
Signed-off-by: wbpcode <wbphub@live.com>
Signed-off-by: wbpcode <wbphub@live.com>
Signed-off-by: wbpcode <wbphub@live.com>
Signed-off-by: wbpcode <wbphub@live.com>
Signed-off-by: wbpcode <wbphub@live.com>
|
Although we used multiple PRs to do some pre-cleanup, this PR still such big. orz. |
|
🍻 finally... |
alyssawilk
left a comment
alyssawilk
left a comment
There was a problem hiding this comment.
this change is AMAZING
I'd bump risk to high just because it's a pretty big refactor. Feel free to merge as is and typedef in a follow-up someone else can review as I'm sure merge conflicts will be a lot.
|
|
||
| BodyFormatter(const envoy::config::core::v3::SubstitutionFormatString& config, | ||
| Server::GenericFactoryContextImpl context) | ||
| Server::Configuration::GenericFactoryContext& context) |
There was a problem hiding this comment.
optional: think it's worth doing a typedef for this one just to avoid the churn here and for folks downstream?
There was a problem hiding this comment.
Sorry, what typedef?
The GenericFactoryContextImpl was just introduced in the #31072 (3 days ago), So, I think the change from GenericFactoryContextImpl to Server::Configuration::GenericFactoryContext&won't effect anyone.
(I used GenericFactoryContextImpl in the #31072 because I hope the FactoryContext could be used to construct a GenericFactoryContextImpl implicitly, then we can reduce unnecessary code change in lots of postions. But now, after this patch, FactoryContext inherit from GenericFactoryContext, so GenericFactoryContextImpl is unnecessary now.)
|
|
||
| absl::StatusOr<std::shared_ptr<DnsCacheImpl>> DnsCacheImpl::createDnsCacheImpl( | ||
| const Server::Configuration::GenericFactoryContext& context, | ||
| Server::Configuration::GenericFactoryContext& context, |
There was a problem hiding this comment.
why the change to non-const?
There was a problem hiding this comment.
Because the scope() method and initManager() method are non-const in the FactoryContext.
An I hope FactoryContext could inherit from GenericFactoryContext but doesn't change the method signatures in the FactoryContext. So, I finally update the method signatures of GenericFactoryContext (because it's only be used in limited positions now.)
I believe this is safe because almost all context is used in non-const mode.
|
Let's me check it last time and then land it. |
- change `context.runtime()` to `context.serverFactoryContext().runtime()` in source/server/http_dynamic_delay_filter_config.cc due to envoyproxy/envoy#31189 and implemented PANIC methods in NighthawkServerFactoryContext - replace `@envoy//source/exe:envoy_common_lib_with_external_headers` with `@envoy//source/exe:all_extensions_lib_with_external_headers` due to envoyproxy/envoy#31109 - replace `@envoy//source/exe:main_common_lib_with_external_headers` with `@envoy//source/exe:main_common_with_all_extensions_lib_with_external_headers` due to a combination of envoyproxy/envoy#30924 and envoyproxy/envoy#31109 causing unit test `UtilityAddressResolutionTest, AddressResolution` failed because `envoy.network.dns_resolver.cares` was not linked in - lower `upstream_cx_rx_bytes_total` counter threshold in `test_http_h2` integration test. - disable oghttp2 in Nighthawk which was enabled by default in Envoy in envoyproxy/envoy@b58d312 - sync files Signed-off-by: Qin Qin <qqin@google.com>
* bump envoy-fork, fix extensions * fix FactoryContext from envoyproxy/envoy#31189 * more build fixes * fix MockFactoryContext * use xds pkg for unified matcher instead of udpa * export the build options * another ServerFactoryContext * use typed_config for lambda filter test * runtime flag...? * runtime flag...as a string...? * use nullopt instead of server factory context. why? not sure yet * put the server factory context back and try a different runtime flag per envoyproxy/envoy#31135 * nuke le asan * uhh * use libcurl, patch out virtual call to ServerFactoryContext::clusterManager() * forgot the patch d'oh * ls on the out dirs * undo commenting creds * add a build dir * derp * what the heck, respect my vars bro * WHY AREN'T WE USING THE RIGHT ENV VARS * look at me. i am the captain now. * shhh, it can't see you if you don't move * well this is nasty but we're getting somewhere * alt+f4 * asan * lower jobs oom-killed * try some more goofiness with the optref * ci shenanigans * server factory context as nullopt * ci nonsense * getting closer * cleanup * remove hard-coding override in initialize() * bump to 1.29.2 * bump to merged --------- Co-authored-by: Nathan Fudenberg <nathan.fudenberg@solo.io>
Relates: envoyproxy/envoy#30765 Relates: envoyproxy/envoy#31189 Signed-off-by: Tam Mach <tam.mach@cilium.io>
2 participants
Commit Message: factory context: refactored factory context
Additional Description:
FactoryContextBaseFactoryContextwon't inherit fromCommonFactoryContext.What should I say? Cheers? 😄
Risk Level: mid.
Testing: n/a.
Docs Changes: n/a.
Release Notes: n/a.
Platform Specific Features: n/a.