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

Introduce PerConnectionState #4454

Merged
merged 13 commits into from
Sep 21, 2018
Merged

Conversation

rshriram
Copy link
Member

@rshriram rshriram commented Sep 18, 2018

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

@rshriram
Copy link
Member Author

This is not complete.. But looking for initial feedback to make sure I am on the right track. cc @ggreenway ..

Copy link
Contributor

@ggreenway ggreenway left a 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()) {
Copy link
Contributor

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.

Copy link
Member Author

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_{};
Copy link
Contributor

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.

* @return Envoy::RequestInfo::FilterState& the state shared between filters operating
* on this connection.
*/
virtual Envoy::RequestInfo::FilterState& perConnectionState() PURE;
Copy link
Contributor

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?

Copy link
Member

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.

Copy link
Member Author

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.

Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>
source/common/tcp_proxy/tcp_proxy.cc Outdated Show resolved Hide resolved
test/common/tcp_proxy/tcp_proxy_test.cc Outdated Show resolved Hide resolved
Shriram Rajagopalan added 2 commits September 19, 2018 19:30
Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>
Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>
Shriram Rajagopalan added 2 commits September 19, 2018 20:26
Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>
Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>
Shriram Rajagopalan added 4 commits September 20, 2018 08:50
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>
@rshriram rshriram changed the title [WIP] Introduce PerConnectionState and use it to override tcp_proxy.cluster Introduce PerConnectionState Sep 20, 2018
@htuch htuch assigned lizan and htuch and unassigned lizan Sep 20, 2018
Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>
Copy link
Member

@htuch htuch left a 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?

@rshriram
Copy link
Member Author

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)

Copy link
Member

@mattklein123 mattklein123 left a 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.

* consumed by many other objects.
* @return the per-connection state associated with this connection.
*/
virtual Envoy::RequestInfo::FilterState& perConnectionState() PURE;
Copy link
Member

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

Copy link
Contributor

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.

Copy link
Contributor

@ggreenway ggreenway Sep 20, 2018

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Filed #4500

@htuch
Copy link
Member

htuch commented Sep 20, 2018

Got it; yeah, if we can avoid referencing RequestInfo, all good.

Copy link
Member

@lizan lizan left a 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>
@rshriram
Copy link
Member Author

merged with master.. mac build is still failing..

Shriram Rajagopalan added 2 commits September 21, 2018 16:43
Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>
Signed-off-by: Shriram Rajagopalan <shriramr@vmware.com>
@ggreenway
Copy link
Contributor

asan failed; looks unrelated. I kicked it off again.

@rshriram
Copy link
Member Author

Thanks.. was just about to ask about that..

@ggreenway ggreenway merged commit 5a3baab into envoyproxy:master Sep 21, 2018
lizan pushed a commit that referenced this pull request Sep 26, 2018
*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>
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.

6 participants