Skip to content
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

Merged
merged 41 commits into from
Jan 30, 2020
Merged

core: integration with Envoy's API listener #616

merged 41 commits into from
Jan 30, 2020

Conversation

junr03
Copy link
Member

@junr03 junr03 commented Dec 19, 2019

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

Jose Nino added 4 commits December 17, 2019 10:08
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>
@junr03
Copy link
Member Author

junr03 commented Dec 19, 2019

FYI @rebello95 @buildbreaker

Jose Nino added 5 commits December 23, 2019 14:53
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>
fmt
Signed-off-by: Jose Nino <jnino@lyft.com>
Jose Nino added 5 commits January 7, 2020 10:24
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>
junr03 added a commit to envoyproxy/envoy that referenced this pull request Jan 17, 2020
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>
mattklein123 pushed a commit to envoyproxy/data-plane-api that referenced this pull request Jan 17, 2020
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
Jose Nino added 2 commits January 17, 2020 15:42
Signed-off-by: Jose Nino <jnino@lyft.com>
Signed-off-by: Jose Nino <jnino@lyft.com>
@stale
Copy link

stale bot commented Jan 21, 2020

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!

@stale stale bot added the stale label Jan 21, 2020
Signed-off-by: Jose Nino <jnino@lyft.com>
@stale stale bot removed the stale label Jan 21, 2020
fmt
Signed-off-by: Jose Nino <jnino@lyft.com>
@junr03 junr03 marked this pull request as ready for review January 21, 2020 17:45
Signed-off-by: Jose Nino <jnino@lyft.com>
@junr03
Copy link
Member Author

junr03 commented Jan 29, 2020

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());
Copy link
Contributor

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.

Copy link
Contributor

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.

Jose Nino added 2 commits January 29, 2020 23:41
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_);
Copy link
Contributor

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.)

Copy link
Member Author

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.

Copy link
Contributor

@goaway goaway left a 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!

@junr03
Copy link
Member Author

junr03 commented Jan 30, 2020

Alright team @goaway @buildbreaker @rebello95 going to merge this. However we can't bump iOS until we fix envoyproxy/envoy#9875

@junr03 junr03 merged commit 38710da into master Jan 30, 2020
@junr03 junr03 deleted the hcm-integration branch January 30, 2020 21:11
rebello95 added a commit that referenced this pull request Feb 14, 2020
As of #616, this is no longer used or necessary since it's handled by the router.

Resolves #643.

Signed-off-by: Michael Rebello <me@michaelrebello.com>
rebello95 added a commit that referenced this pull request Feb 19, 2020
As of #616, this is no longer used or necessary since it's handled by the router.

Resolves #643.

Signed-off-by: Michael Rebello <me@michaelrebello.com>
jpsim pushed a commit to envoyproxy/envoy that referenced this pull request Nov 28, 2022
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>
jpsim pushed a commit to envoyproxy/envoy that referenced this pull request Nov 29, 2022
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

core: support L7 C++ filter chain
4 participants