listener: create internal listener#18104
Conversation
Signed-off-by: Yuchen Dai <silentdai@gmail.com>
Signed-off-by: Yuchen Dai <silentdai@gmail.com>
Signed-off-by: Yuchen Dai <silentdai@gmail.com>
Signed-off-by: Yuchen Dai <silentdai@gmail.com>
Signed-off-by: Yuchen Dai <silentdai@gmail.com>
Signed-off-by: Yuchen Dai <silentdai@gmail.com>
Signed-off-by: Yuchen Dai <silentdai@gmail.com>
|
Talked to @yanavlasov about this PR. |
Signed-off-by: Yuchen Dai <silentdai@gmail.com>
Signed-off-by: Yuchen Dai <silentdai@gmail.com>
Signed-off-by: Yuchen Dai <silentdai@gmail.com>
Signed-off-by: Yuchen Dai <silentdai@gmail.com>
Signed-off-by: Yuchen Dai <silentdai@gmail.com>
Signed-off-by: Yuchen Dai <silentdai@gmail.com>
Signed-off-by: Yuchen Dai <silentdai@gmail.com>
Signed-off-by: Yuchen Dai <silentdai@gmail.com>
|
@envoyproxy/senior-maintainers assignee is @ggreenway |
| /** | ||
| * Configuration for an internal listener. | ||
| */ | ||
| class InternalListenerConfig { |
There was a problem hiding this comment.
It looks like this isn't used yet for anything. Delete until it's needed?
There was a problem hiding this comment.
This is used by the ConnectionHandler to determine if the listener type is Internal.
I feel this is cleaner than find the listen address and query the address type then dispatch by the address type.
In fact I almost make the ConnectionHandler not relying on the address type.
Signed-off-by: Yuchen Dai <silentdai@gmail.com>
|
@ggreenway I resolve most of them except introducing the empty InternalListenerConfig interface. PTAL |
ggreenway
left a comment
There was a problem hiding this comment.
I think you need to validate listener config to make sure all the tcp-socket specific options aren't set. Such as tcp-fast-open, socket options, keepalive, mptcp, reuse_port, etc.
|
/wait |
Signed-off-by: Yuchen Dai <silentdai@gmail.com>
|
/retest |
|
Retrying Azure Pipelines: |
|
/retest |
|
Retrying Azure Pipelines: |
|
/retest |
|
Retrying Azure Pipelines: |
source/server/listener_impl.cc
Outdated
| void ListenerImpl::buildInternalListener() { | ||
| if (config_.address().has_envoy_internal_address()) { | ||
| internal_listener_config_ = std::make_unique<Network::InternalListenerConfig>(); | ||
| if (config_.has_connection_balance_config() || config_.enable_mptcp() || |
There was a problem hiding this comment.
Does anything go wrong if this is thrown after buildFilterChains has already run? I can't remember if that has any interaction with the previous config on the listener. If there's any risk, you could move this into validateConfig() to do it earlier.
There was a problem hiding this comment.
As long as the exception was thrown prior to ListenerImpl::initialize(), there is no risk to wrongly deem the exception as a signal of "listener is wamed up".
We don't cross the line here
There was a problem hiding this comment.
api listener is handled early: Api listener config doesn't instantiate ListenerImpl but HttpApiListener
I add a test in listenerimpl pretending that some how a listenerImpl is constructed with Apilistener. Though in production it will never hit :)
There was a problem hiding this comment.
A separate question to @junr03: should we reject api listener with internal address?
https://github.com/envoyproxy/envoy/blob/main/source/server/api_listener_impl.h#L39
source/server/listener_impl.cc
Outdated
| if (config_.has_connection_balance_config() || config_.enable_mptcp() || | ||
| config_.has_enable_reuse_port() || config_.has_freebind() || | ||
| config_.has_tcp_backlog_size() || config_.has_tcp_fast_open_queue_length() || | ||
| config_.has_transparent()) { |
There was a problem hiding this comment.
|| config_.enable_mptcp(). And maybe has_api_listener()?
For all of the BoolValue's, I think it's still valid if it is present, but set to false.
This validation is going to be a big mess. Maybe it's not worth doing. Any guidance from @envoyproxy/api-shepherds on what validation to do for mutually-incompatible options?
There was a problem hiding this comment.
re: it's still valid if it is present. Right, Let me fix immediately.
Regarding the high level validation, I remember we opened an issue to move the tcp only options to a dedicated tcp listener config, though there was no solid move. That would be the long term fix.
Another fact is that Udp listener doesn't validate tcp options, just ignore.
I will add the quick fix on the validation here and leave api shephereds to the final call.
Signed-off-by: Yuchen Dai <silentdai@gmail.com>
|
/retest |
|
Retrying Azure Pipelines: |
ggreenway
left a comment
There was a problem hiding this comment.
I think this is pretty good. It's possible that we'll want to change some of the details as you complete the other parts of this (large) feature, but this is good enough for moving on to the next steps.
|
Thank you @ggreenway @yanavlasov |
Commit Message:
Implements internal listener.
This PR allows creating server connection but the abilitity to connect to such a listener is located in #18105.
Additional Description:
Risk Level: LOW. Not impacting existing TCP/UDP listener.
Testing: Mostly unit test since the dispatcher is not yet ready to create pair of internal connections.
Docs Changes:
Release Notes:
Platform Specific Features:
Runtime guard:
envoy.reloadable_features.internal_addressto allow/reject internal listener config.[Optional Fixes #Issue]
[Optional Deprecated:]
[Optional API Considerations:]