-
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
Introduce PerConnectionState #4454
Conversation
This is not complete.. But looking for initial feedback to make sure I am on the right track. cc @ggreenway .. |
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.
The direction of this looks right.
We need to decide exactly what data we're storing per-connection, and where to store it. But the codes changes for those decisions should be pretty small.
Also, I'd like to make sure other @envoyproxy/maintainers agree with this direction. Thoughts?
@@ -49,7 +49,8 @@ ConnectionImpl::ConnectionImpl(Event::Dispatcher& dispatcher, ConnectionSocketPt | |||
socket_(std::move(socket)), write_buffer_(dispatcher.getWatermarkFactory().create( | |||
[this]() -> void { this->onLowWatermark(); }, | |||
[this]() -> void { this->onHighWatermark(); })), | |||
dispatcher_(dispatcher), id_(next_global_id_++) { | |||
dispatcher_(dispatcher), id_(next_global_id_++), | |||
per_connection_state_(Envoy::RequestInfo::FilterStateImpl()) { |
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.
This stores a reference to a temporary. I don't think you really want a reference here.
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.
Oops! I hacked up something quickly. Will clean all this up.
@@ -123,6 +125,8 @@ class ConnectionImpl : public virtual Connection, | |||
TransportSocketPtr transport_socket_; | |||
FilterManagerImpl filter_manager_; | |||
ConnectionSocketPtr socket_; | |||
Envoy::RequestInfo::FilterStateImpl& per_connection_state_{}; |
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.
This should probably be a unique_ptr or a value, but not a reference.
include/envoy/network/connection.h
Outdated
* @return Envoy::RequestInfo::FilterState& the state shared between filters operating | ||
* on this connection. | ||
*/ | ||
virtual Envoy::RequestInfo::FilterState& perConnectionState() PURE; |
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.
Design question: should this be a full RequestInfo, instead of just the FilterState?
Also, should this live on the ReadFilterCallbacks, instead of on the Connection?
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.
ReadFilterCallbacks has connection()
, I think it is good to have this in Connection.
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.
RequestInfo does not seem to be related to FilterState, eventhough they are both under the same namespace. Doing so, would require exposing a RequestInfo accessor to get the Filterstate and making sure that the RequestInfo constructors will allocate the filterState as well.
425b2f7
to
51520a8
Compare
Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>
51520a8
to
be1290c
Compare
Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>
Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>
Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>
Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>
Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>
Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>
Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>
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 might well be missing the context here, but I had initially thought the idea was to provide a connection-level variant of #3918. Should we reuse most of the data structures in #3918 for this?
Or, is the idea to provide some connection level properties and share them between filters, similar to RequestInfo
?
This is the connection level variant of #3918.. All we need is to store the shared filter state and have an accessor for it in the Connection interface (similar to how RequestInfo has an accessor for perRequestState) |
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.
Yup this looks like the right direction to me @rshriram and @ggreenway. Excited to see this.
include/envoy/network/connection.h
Outdated
* consumed by many other objects. | ||
* @return the per-connection state associated with this connection. | ||
*/ | ||
virtual Envoy::RequestInfo::FilterState& perConnectionState() PURE; |
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.
nit: It doesn't thrill me that this is in the RequestInfo
namespace since this has nothing to do with requests at this point. Can we move to some other sensibly named namespace (or an existing one)?
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.
This all came about because I added access logging to TcpProxy, and reused the existing RequestInfo. So the state of things right now is that RequestInfo is used in both http requests and tcp proxy connections. And some of the logging fields are documented as behaving differently in tcp proxy.
I think we can probably leave the code mostly alone, and just come up with a better name than RequestInfo that encompasses both use cases. But names are hard, and I don't have a good idea.
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.
@htuch @mattklein123 How about we leave this PR as-is and file an issue to rename the class/namespace for this stuff?
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.
+1
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.
OK SGTM. I can't immediately think of a better name right now anyway.
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.
ConnectionInfo? I think it makes clearer the L4 nature if we're not multiplexing. Streams/flows to me conjure up L7 H2.
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 think we are find a generic name for both L4/L7? if so StreamInfo SGTM.
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.
Oh, I see. Sure, StreamInfo.
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.
We could always subclass/typedef for the respective Connection/Request variants.
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.
Filed #4500
Got it; yeah, if we can avoid referencing |
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, can you merge master to fix mac CI build?
Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>
merged with master.. mac build is still failing.. |
Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>
asan failed; looks unrelated. I kicked it off again. |
Thanks.. was just about to ask about that.. |
*Description*: Use the SNI value as the upstream cluster name. This is similar to the cluster_header feature in HCM. Leverages the perConnectionState to dynamically control the cluster used by tcp_proxy filter. We plan to use this in Istio, where Pilot would manage two kubernetes setups, such that the envoys will have the same set of clusters, but the non-local clusters will have the IP of a Gateway envoy (edge/front envoy). mTLS traffic arriving at the gateway envoy will be routed to the internal (envoy)clusters based on the SNI value Depends on #4454 *Risk Level*: Low *Testing*: Unit tests *Docs Changes*: yes *Release Notes*: yes Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>
Signed-off-by: Shriram Rajagopalan shriramr@vmware.com
Description: Introduce per connection state for state sharing across network filters, similar to HTTP filters
Risk Level: low