-
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
Xds mux unification: introduced unifed mux implementation #17352
Conversation
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Supersedes #17049. |
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
@adisuissa could you take a first pass? Thanks. |
Signed-off-by: Dmitri Dolguikh <[email protected]>
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.
Sorry for the review delay, some questions to kick off.
} | ||
|
||
template <class S, class F, class RQ, class RS> | ||
void GrpcMuxImpl<S, F, RQ, RS>::trySendDiscoveryRequests() { |
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.
Is it fair to say that this new unified mux is most similar to the existing NewGrpcMuxImpl
? If a reviewer were to compare the two side-by-side, what would be the key differences or things to pay attention to?
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.
Is it fair to say that this new unified mux is most similar to the existing NewGrpcMuxImpl.
Definitely. Will add some pointers here a bit later.
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 most significant source of difference between the implementations is introduction of templates; most of the time there's little to none difference in logic in methods.
- There's no
SubscriptionStuff
in the unified mux implementation; b/c of that creating/accessing subscription state is a bit different. - Both delta and sotw muxes in the new implementation respect
skip_subsequent_node
flag; the flag is used insendGrpcMessage()
method. - Concrete mux classes are tiny, pretty much all of the logic is in the base class.
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.
Thanks, very helpful, CC @adisuissa
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.
Thanks a lot for working on this!
Here's a first-pass comments/questions I've got.
void NullGrpcMuxImpl::updateWatch(const std::string&, Watch*, | ||
const absl::flat_hash_set<std::string>&, | ||
const SubscriptionOptions&) { | ||
throw EnvoyException("ADS must be configured to support an ADS config source"); | ||
} | ||
|
||
void NullGrpcMuxImpl::removeWatch(const std::string&, Watch*) { | ||
throw EnvoyException("ADS must be configured to support an ADS config source"); | ||
} |
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: implement these directly in the header file
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 now have a check that yells if exceptions are being raised in headers, which makes me think that such an approach should be used sparingly?
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.
Yeah, no exception throwing in headers :) @adisuissa we have an internal requirement around this.
source/common/config/grpc_mux_impl.h
Outdated
bool paused(const std::string&) const override { return false; } | ||
void updateWatch(const std::string&, Watch*, const absl::flat_hash_set<std::string>&, | ||
const SubscriptionOptions&) override; | ||
void removeWatch(const std::string&, Watch*) override; | ||
void requestOnDemandUpdate(const std::string&, const absl::flat_hash_set<std::string>&) override { | ||
NOT_IMPLEMENTED_GCOVR_EXCL_LINE; |
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.
Why is this not implemented and the other methods throw an exception (ADS must be configured)?
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.
Hmm, I don't feel strongly about this; my thinking was that requestOnDemandUpdate
only makes sense for a delta mux, so all other implementations panic. I can throw an exception here if you think it's easier to understand/read.
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 shouldn't assume that delta implies ADS though if that's what is suggested.
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 do think the original message in the exception is weird (see also here: https://github.com/envoyproxy/envoy/blob/main/source/common/config/grpc_mux_impl.h#L215). Perhaps a simple panic would suffice in those places? I could a separate PR to update the message in legacy mux implementation.
@@ -88,28 +101,73 @@ class NewGrpcMuxImplTestBase : public testing::Test { | |||
EXPECT_CALL(async_stream_, sendMessageRaw_(Grpc::ProtoBufferEq(expected_request), false)); | |||
} | |||
|
|||
void remoteClose() { | |||
if (isUnifiedMuxTest()) { | |||
dynamic_cast<XdsMux::GrpcMuxDelta*>(grpc_mux_.get()) |
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.
It may be better to only cast in the if clause, and then apply the ->grpcStreamForTest().onRemoteClose(Grpc::Status::WellKnownGrpcStatus::Canceled, "");
outside of the if clause. (Should improve maintenance down the road).
Also applies to the functions below.
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.
Not sure what you mean here: grpcStreamForTest()
isn't in the mux interface, concrete mux types are needed to invoke it. There isn't a common base between XdsMux::GrpcMuxDelta
and NewGrpcMuxImpl
, I can't declare a local var to hold the result of such cast...
@@ -126,11 +184,17 @@ TEST_F(NewGrpcMuxImplTest, DynamicContextParameters) { | |||
// Update to bar type should resend Node. | |||
expectSendMessage("bar", {}, {}); | |||
local_info_.context_provider_.update_cb_handler_.runCallbacks("bar"); | |||
expectSendMessage("foo", {}, {"x", "y"}); | |||
if (!isUnifiedMuxTest()) { | |||
// in "legacy" delta mux implementation destruction of "foo_sub" |
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.
Is this due to an issue in the legacy-delta implementation? Is there an issue# to add to this?
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.
Nods, In NewGrpcMuxImpl addWatch
call returns a wrapper a Watch
, which also has a dtor (here: https://github.com/envoyproxy/envoy/blob/main/source/common/config/new_grpc_mux_impl.h#L114) that's being called when foo_sub
goes out of scope, and an unsubscribe message is sent. Unified mux implementation returns a thin wrapper around a Watch
that's there for compatibility with existing interface only (So I don't need to introduce a very similar addWatch
method). This compatibility wrapper doesn't have perform an unsubscribe on destruction, hence the difference.
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
|
/retest |
Retrying Azure Pipelines: |
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
This reverts commit 5ac0553. Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
This reverts commit 2a7a5af. Signed-off-by: Dmitri Dolguikh <[email protected]>
This reverts commit 58837b7. Signed-off-by: Dmitri Dolguikh <[email protected]>
This reverts commit de40b51. Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
This reverts commit cda496e. Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
This reverts commit 1e58a3d. Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
Signed-off-by: Dmitri Dolguikh <[email protected]>
@htuch: this should be good once #17767 has been merged. Thank you and @adisuissa for reviews. A huge thank you to @davinci26, who helped with test failures under Windows. |
Signed-off-by: Dmitri Dolguikh <[email protected]>
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, thanks!
@@ -21,6 +21,7 @@ declare -a KNOWN_LOW_COVERAGE=( | |||
"source/common/quic:91.2" | |||
"source/common/tracing:96.1" | |||
"source/common/watchdog:42.9" # Death tests don't report LCOV | |||
"source/common/config/xds_mux:94.5" |
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.
Sorry, coming in late, why did this need a coverage exemption?
Commit Message:
Additional Description: PR #2 out of 3. Introduces unified mux implementation
Risk Level: Low, nor enabled atm
Testing: Updated tests
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Deprecated:]
[Optional API Considerations:]
Ping @htuch