-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
core: integration with Envoy's API listener #616
Conversation
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
Description: this PR introduces the initial implementation of an Api Listener based on the proto configuration merged in #8170. Notably, this PR introduces the ability to add only _one_ api listener via _bootstrap config only_. This decision was made in order to iterate into more complex setups (multiple listeners, LDS supplied listeners) in subsequent PRs. Moreover, the API listener is created in the context of Envoy's main thread not worker threads. A first use of this Api Listener can be seen in envoyproxy/envoy-mobile#616. Risk Level: low, only used in Envoy Mobile. The risk here is about building something generally useful and flexible. Note however that a couple of things were rejiggered in the HCM. Testing: unit and integration tests. Additional testing in https://github.com/lyft/envoy-mobile. Docs Changes: Added inline comments and TODOs. Proto documentation is up-to-date. Release Notes: similar to doc changes. Signed-off-by: Jose Nino <jnino@lyft.com>
Description: this PR introduces the initial implementation of an Api Listener based on the proto configuration merged in envoyproxy/envoy#8170. Notably, this PR introduces the ability to add only _one_ api listener via _bootstrap config only_. This decision was made in order to iterate into more complex setups (multiple listeners, LDS supplied listeners) in subsequent PRs. Moreover, the API listener is created in the context of Envoy's main thread not worker threads. A first use of this Api Listener can be seen in envoyproxy/envoy-mobile#616. Risk Level: low, only used in Envoy Mobile. The risk here is about building something generally useful and flexible. Note however that a couple of things were rejiggered in the HCM. Testing: unit and integration tests. Additional testing in https://github.com/lyft/envoy-mobile. Docs Changes: Added inline comments and TODOs. Proto documentation is up-to-date. Release Notes: similar to doc changes. Signed-off-by: Jose Nino <jnino@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ 9b6260fcf6ee1299744b8e5c76c1e6d9d36f7c89
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
cc @mattklein123 in case you want to take a look as well. |
http_dispatcher_->ready(server->dispatcher(), server->clusterManager()); | ||
auto api_listener = server->listenerManager().apiListener()->get().http(); | ||
ASSERT(api_listener.has_value()); | ||
http_dispatcher_->ready(server->dispatcher(), api_listener.value()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this additional delay (beyond construction) still necessary? We're no longer waiting on an initial round of DNS resolution and the filter dynamic forwarding filter contains built in buffering logic while we do wait. If we're unsure, maybe insert a TODO to follow up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still suggest adding a TODO and/or issue for this so we still have visibility to follow up.
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
// means that instead of efficiently queuing the deletes for one event in the event loop, all | ||
// deletes here get queued up as individual posts. | ||
TS_UNCHECKED_READ(event_dispatcher_)->post([direct_stream]() -> void { | ||
ENVOY_LOG(debug, "[S{}] deferred deletion of stream", direct_stream->stream_handle_); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just want to be sure that the optimizer won't optimize away this capture of direct_stream
- even if ENVOY_LOG
is compiled away. (Even if this would definitively/arguably be an optimizer bug, I've seen this sort of thing happen before.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really enjoy your eye for things that might end up being subtle bugs in the future. https://stackoverflow.com/a/12718425 and the comments below state that an explicit capture like above will not be optimized out even if the variable is not used in the lambda body.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work. Thanks @junr03!
Alright team @goaway @buildbreaker @rebello95 going to merge this. However we can't bump iOS until we fix envoyproxy/envoy#9875 |
As of envoyproxy/envoy-mobile#616, this is no longer used or necessary since it's handled by the router. Resolves envoyproxy/envoy-mobile#643. Signed-off-by: Michael Rebello <me@michaelrebello.com> Signed-off-by: JP Simard <jp@jpsim.com>
As of envoyproxy/envoy-mobile#616, this is no longer used or necessary since it's handled by the router. Resolves envoyproxy/envoy-mobile#643. Signed-off-by: Michael Rebello <me@michaelrebello.com> Signed-off-by: JP Simard <jp@jpsim.com>
Description: this PR integrates Envoy's ApiListener to replace Envoy Mobile's use of the AsyncClient. Doing so gives Envoy Mobile access to all L7 facilities provided by Envoy's Http Connection Manager; including but no limited to the L7 filters.
Risk Level: HIGH! This PR changes the underlying code for Envoy Mobile's core functionality
Testing: unit tests updated for the dispatcher, integration tests, and e2e tests with the example apps. Additionally, the ApiListener code has been unit and integration tested in Envoy.
Fixes #543