-
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
Use on-demand cluster discovery in on-demand extension #20065
Conversation
Signed-off-by: Krzesimir Nowak <[email protected]>
Signed-off-by: Krzesimir Nowak <[email protected]>
Signed-off-by: Krzesimir Nowak <[email protected]>
Signed-off-by: Krzesimir Nowak <[email protected]>
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
Signed-off-by: Wanli Li <[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.
Thanks for working on this, very exciting!
Took a first pass on the code, and left a few comments.
// service. If not specified, the on-demand cluster discovery will | ||
// be disabled. When it's specified, the filter will pause a request |
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.
Do you think that this field should be required?
IMO if a config update contains the OnDemand
extension, then it is meant to be used (and enabled).
Unless if there are scenarios where a dummy placeholder is wanted.
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 that before the on-demand plugin was only talking to RDS if there wasn't any matching route. Not sure if we want to break this by requiring the odcds_config to be defined.
// service. If not specified, the on-demand cluster discovery will | ||
// be disabled. When it's specified, the filter will pause a request |
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.
Same as above
Upstream::OdCdsApiHandlePtr createOdCdsApi(const ProtoConfig& proto_config, | ||
Upstream::ClusterManager& cm, | ||
ProtobufMessage::ValidationVisitor& validation_visitor) { | ||
if (!proto_config.has_odcds_config() && proto_config.resources_locator().empty()) { |
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.
IIRC the config-source is required no matter if resources-locator is set or not.
@htuch to correct me if I'm wrong.
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, my confusion here. I was reading this as resource-name instead of locator.
filter_iteration_state_ = Http::FilterHeadersStatus::StopIteration; | ||
auto callback = std::make_unique<Upstream::ClusterDiscoveryCallback>( | ||
[this](Upstream::ClusterDiscoveryStatus cluster_status) { | ||
onClusterDiscoveryCompletion(cluster_status); |
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.
Could there be a case where the filter is destroyed before the callback is invoked?
What I'm not certain about is whether we'll get an invocation of onClusterDiscoveryCompletion
on a destroyed filter.
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.
If the filter is destroyed, then cluster_discovery_handle_
is going to be destroyed too, which will unregister and destroy the callback.
/wait |
Signed-off-by: Krzesimir Nowak <[email protected]>
Signed-off-by: Krzesimir Nowak <[email protected]>
/wait |
Signed-off-by: Krzesimir Nowak <[email protected]>
@adisuissa could you please take a look when you get a moment? Thanks! |
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.
Overall LGTM.
/assign @htuch
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 modulo remaining comments.
/wait
Signed-off-by: Krzesimir Nowak <[email protected]>
Signed-off-by: Krzesimir Nowak <[email protected]>
Signed-off-by: Krzesimir Nowak <[email protected]>
Signed-off-by: Krzesimir Nowak <[email protected]>
Signed-off-by: Krzesimir Nowak <[email protected]>
Signed-off-by: Krzesimir Nowak <[email protected]>
/retest |
Retrying Azure Pipelines: |
CI is green, so it's ready for review. |
Thanks again, @krnowak -- fantastic work, I really appreciate it. |
Signed-off-by: Krzesimir Nowak <[email protected]>
@jamesmulcahy: Thank you for the kind words. :) I updated the PR again, this time no code changes (besides another merge from the main branch), but the CI needs to run again. I found out that there are some extra docs for on_demand extension, so I tried my hand at updating them a bit. I'd be grateful for a review of the wording. Thanks! |
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 with two nits (look forward to getting this mergred)
docs/root/configuration/http/http_filters/on_demand_updates_filter.rst
Outdated
Show resolved
Hide resolved
Signed-off-by: Krzesimir Nowak <[email protected]>
Signed-off-by: Krzesimir Nowak <[email protected]>
Signed-off-by: Krzesimir Nowak <[email protected]>
Signed-off-by: Krzesimir Nowak <[email protected]>
Signed-off-by: Krzesimir Nowak <[email protected]>
Signed-off-by: Krzesimir Nowak <[email protected]>
Signed-off-by: Krzesimir Nowak <[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! Huge win for xDS APIs, thank you so much @krnowak for your contributions here and patience through the review process.
) This adds an odcds_config field to the extension's config, and also allows the extension to be configured per-route. As it stands, it currently works only with routes using cluster-header config. Risk Level: Medium, extending one extension in an opt-in way. Testing: Added unit tests and integration tests. Fixes envoyproxy#2500 Signed-off-by: Krzesimir Nowak <[email protected]>
Commit Message:
This adds an odcds_config field to the extension's config, and also allows the extension to be configured per-route. As it stands, it currently works only with routes using cluster-header config.
Additional Description:
Risk Level:
Medium, extending one extension in an opt-in way.
Testing:
Added unit tests and integration tests.
Docs Changes:
Not sure.
Release Notes:
Extended on-demand extension with on-demand cluster discovery functionality.
Platform Specific Features:
None.
[Optional Runtime guard:]
Fixes #2500
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]
CC: @jamesmulcahy