mobile: allow using a light listener manager#24363
mobile: allow using a light listener manager#24363alyssawilk merged 21 commits intoenvoyproxy:mainfrom
Conversation
|
CC @envoyproxy/mobile-maintainers: FYI only for changes made to |
f0d0fb7 to
fdc3eaa
Compare
|
/retest |
|
Retrying Azure Pipelines: |
1dc4db7 to
fdc3eaa
Compare
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
fdc3eaa to
c19cdd7
Compare
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
.github/workflows/android_tests.yml
Outdated
| --build_tests_only \ | ||
| $([ -z $GITHUB_TOKEN ] || echo "--config=remote-ci-linux-clang") \ | ||
| --remote_header="Authorization=Bearer $GITHUB_TOKEN" \ | ||
| --copt=-DALLOW_TCP_LISTENERS --remote_header="Authorization=Bearer $GITHUB_TOKEN" \ |
There was a problem hiding this comment.
Can this be moved to a .bazelrc config?
There was a problem hiding this comment.
The goal here is to have E-M build without TCP listeners, but we exempt it for this CI due to the proxying tests. will comment inline.
There was a problem hiding this comment.
But then these tests will fail when run locally?
Why not add build test --copt=-DALLOW_TCP_LISTENERS to the .bazelrc so it works both on CI and locally?
There was a problem hiding this comment.
because then all tests will always run with TCP listeners, and we won't have regression testing for, say, the C++ tests running without TCP listeners.
What I'm hearing is you'd prefer I add it to the bazelrc, and explicitly not allow TCP listeners on all the non-legacy CI instead?
There was a problem hiding this comment.
Hmm, yeah I was thinking a config that we could pass when running these tests specifically, but then it doesn't make much difference if you have to pass a config or a --copt because either way ./bazelw test ... won't be sufficient.
I'm ok keeping this as-is then.
Why does Kotlin need to build with the real listener? |
We have release notes in https://github.com/envoyproxy/envoy/blob/main/mobile/docs/root/intro/version_history.rst |
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
|
Also adding in Snow for the changes to Envoy. Mind taking a look? Very minimal PR. |
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
|
A discussion related to this PR happened in Slack. The current hypothesis is that #24294 broke objc hello world app CI job which was disabled in #24363 to 'unblock' main (make it green again). We think that your PR may fix objc hello world app issue but to test it we would need to re-enable the aforementioned job. Could we verify whether your PR fixes the objc hello world app CI job? |
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
|
Ok CI reinstated and passing (needed a different force-register) |
Commit Message: Additional Description: Register default listener. Envoy Mobile crashes in optimized builds without this change. The crash was introduced in #24294. The objc hello world app CI job was disabled in #24363 to make main green again. Risk Level: Low Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
mobile/envoy_build_config/BUILD
Outdated
| deps = [ | ||
| "extension_registry_platform_additions", | ||
| "@envoy//source/common/network:socket_lib", | ||
| "@envoy//source/common/quic:quic_transport_socket_factory_lib", |
There was a problem hiding this comment.
This may be missing envoy_select_enable_http3 usage https://github.com/envoyproxy/envoy/pull/24496/files#diff-4517a4a52636c1c8e390c1d9653aa000a67fc1070d977ebc114ca9eacac2ec49R48
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
It's needed by Android proxy tests which spam 2 instances of Envoy Mobile, one of which acts as a "fake" proxy and uses the default/complex listener to handle incoming requests. |
Augustyniak
left a comment
There was a problem hiding this comment.
Left a comment with regard to including the new api listener based on the value of the introduced flag.
It's not a hard blocker but it's worth noting that the size of the binary will actually go up by a tiny bit until we do not remove the old listener and if we always include the new listener as part of the build. Based on JP's numbers for the size increase I am not worried about the size increase tho (as it appears to be tiny).
| Envoy::Network::forceRegisterGetAddrInfoDnsResolverFactory(); | ||
| Envoy::Extensions::RequestId::forceRegisterUUIDRequestIDExtensionFactory(); | ||
| Envoy::Server::forceRegisterDefaultListenerManagerFactoryImpl(); | ||
| Envoy::Server::forceRegisterApiListenerManagerFactoryImpl(); |
There was a problem hiding this comment.
should we force register in here only if DUSE_API_LISTENER is set?
There was a problem hiding this comment.
I was going to do that but I think it requires a bazel flag and additional plumbing to be useful given the library include
| "@envoy_mobile//library/common/extensions/filters/http/platform_bridge:config", | ||
| "@envoy_mobile//library/common/extensions/filters/http/route_cache_reset:config", | ||
| "@envoy_mobile//library/common/extensions/filters/http/socket_tag:config", | ||
| "@envoy_mobile//library/common/extensions/listener_managers/api_listener_manager:api_listener_manager_lib", |
There was a problem hiding this comment.
similar to my other comment - should we include this dep only if the new compiler/build flag is set?
There was a problem hiding this comment.
I think it depends. if the long term plan is to have a bazel flag to have it optional, we can add it now. if long term we want to say E-M is a client library not a proxy, I'm inclined to not do the busy-work which I'd then have to unwind, and accept the additional include in the interim (we can remove it in-housE)
There was a problem hiding this comment.
actually having thought a bit more I think it is sensible to have a flag but I would like to add it when we flip the default, so have one for "enable TCP listener" where right now we have compile support for "enable API listener"
This enables using Envoy Mobile from the real downstream listener manger to a lightweight listener manager, allowing compiling out all the downstream listener code.
The real listener is still by default. This should be largely a no-op for everything but the c++ CI.
Risk Level: low
Testing: c++ ci regression tests new code paths.
Docs Changes: n/a
Release Notes: n/a
Part of envoyproxy/envoy-mobile#2711