-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
original_dst listener filter: implement internal listener support #29655
Conversation
Signed-off-by: Kuat Yessenov <kuat@google.com>
/assign-from @envoyproxy/envoy-maintainers |
@envoyproxy/envoy-maintainers assignee is @snowp |
/retest |
/assign-from @envoyproxy/envoy-maintainers |
@envoyproxy/envoy-maintainers assignee is @snowp |
/assign-from @envoyproxy/envoy-maintainers |
@envoyproxy/envoy-maintainers assignee is @snowp |
/assign-from @envoyproxy/envoy-maintainers |
@envoyproxy/envoy-maintainers assignee is @htuch |
|
||
Dynamic metadata for the destination address is expected to be placed into the | ||
key `envoy.filters.listener.original_dst` under the field `local` and should | ||
contain a string with an IP and a port address. |
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.
Looking at the existing use of original_dst and this form, it seems the contract with the rest of Envoy is different. This new use case is about populating filter state, rather than original_dst cluster. Feels a bit overloaded, should there be some plans to separate source of information in some consistent metadata from consumption?
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.
Are you thinking of a "common" metadata for the destination? This change is about consuming a filter state and metadata, so the typical chain is the following:
- Some listener/cluster that produces filter state and/or metadata to an internal address.
- Internal listener with original_dst listener filter.
- Any cluster, common to have original_dst cluster here.
I was thinking that original_dst listener filter updates the addresses, we no longer need to modify original_dst cluster. But it already has a filter state defined for the same purpose, so we could reuse the same object. This approach might interfere with normal original_dst cluster behavior because filter state takes priority and there is no way to delete a filter state object.
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.
Are you saying we're using the same filter state as the existing original_dst cluster? If so, I suggest refactoring the docs to make this explicit.
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.
No, we're using different filter states. ORIGINAL_DST cluster uses envoy.network.transport_socket.original_dst_address. original_dst listener filter uses envoy.filters.listener.original_dst.local_ip
. I thought you suggested to share them? I think it's safer not to share.
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 did a bit of refactoring to make it clear that ORIGINAL_DST cluster and filter share the object but have different keys.
EXPECT_TRUE(socket_.connectionInfoProvider().localAddressRestored()); | ||
EXPECT_EQ(local->asString(), socket_.connectionInfoProvider().localAddress()->asString()); | ||
EXPECT_EQ(remote->asString(), socket_.connectionInfoProvider().remoteAddress()->asString()); | ||
} |
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.
Does an integration test make sense?
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 don't think it's strictly necessary - the override doesn't affect the data path of original_dst, only where the data comes from. But if you feel like we need it, I can add it. It would need 4 extensions (original_dst filter and cluster, internal listener and upstream).
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.
LGTM, feel free to merge if you think this is done.
Signed-off-by: Kuat Yessenov <kuat@google.com>
This should be ready now, @htuch PTAL again. |
Commit Message: Adds support for recovery of the local and the remote addresses in the internal connections using the original_dst listener filter. This supports two use cases:
Additional Description:
Risk Level: low, new feature
Testing: added
Docs Changes: yes
Release Notes: yes
Issue: #29652
issue: #29681