Skip to content

upstream: include locality_weights when the cluster uses a load balancing extension#17947

Merged
snowp merged 4 commits intoenvoyproxy:mainfrom
pianiststickman:locality-weights
Sep 3, 2021
Merged

upstream: include locality_weights when the cluster uses a load balancing extension#17947
snowp merged 4 commits intoenvoyproxy:mainfrom
pianiststickman:locality-weights

Conversation

@pianiststickman
Copy link
Copy Markdown
Contributor

locality_weights is currently calculated only when the cluster contains a common_lb_config containing a locality weighted config. This allows load balancing extensions to receive locality_weights.

In the future, it might be preferable to have the load balancing policy indicate, programatically, whether it needs the locality weights, as an optimization in cases where it doesn't.

This commit also pulls the custom LB used in CustomStaticCluster into its own library so that it can be re-used.

Signed-off-by: Eugene Chan eugenechan@google.com

Commit Message: upstream: include locality_weights when the cluster uses a load balancing extension
Additional Description:
locality_weights is currently calculated only when the cluster contains a common_lb_config containing a locality weighted config. This allows load balancing extensions to receive locality_weights.

In the future, it might be preferable to have the load balancing policy indicate, programatically, whether it needs the locality weights, as an optimization in cases where it doesn't.

This commit also pulls the custom LB used in CustomStaticCluster into its own library so that it can be re-used.
Risk Level: low
Testing: new unit test
Docs Changes: n/a
Release Notes: includes locality_weights for load balancing extensions
Platform Specific Features: n/a

balancing extension

`locality_weights` is currently calculated only when the cluster contains
a `common_lb_config` containing a locality weighted config. This allows
load balancing extensions to receive `locality_weights`.

In the future, it might be preferable to have the load balancing policy
indicate, programatically, whether it needs the locality weights, as an
optimization in cases where it doesn't.

This commit also pulls the custom LB used in `CustomStaticCluster` into
its own library so that it can be re-used.

Signed-off-by: Eugene Chan <eugenechan@google.com>
Signed-off-by: Eugene Chan <eugenechan@google.com>
@yanavlasov yanavlasov self-assigned this Sep 1, 2021
@htuch
Copy link
Copy Markdown
Member

htuch commented Sep 2, 2021

@snowp would you be able to help review this one? It's a pretty small fix and will help us out in our use of LB extensions. Thanks.

Copy link
Copy Markdown
Contributor

@snowp snowp left a comment

Choose a reason for hiding this comment

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

This seems reasonable to me, just a small comment

@@ -1472,7 +1472,9 @@ void PriorityStateManager::updateClusterPrioritySet(
std::vector<HostVector> per_locality;

// If we are configured for locality weighted LB we populate the locality weights.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Maybe update this comment with the reasoning for including this for lb policies? My understand is that the extension may want to use this, so we include this just in case. Maybe even a TODO to have this happen only if the extension requests it somehow

Copy link
Copy Markdown
Contributor Author

@pianiststickman pianiststickman Sep 2, 2021

Choose a reason for hiding this comment

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

Done and done. Your understanding matches mine - we don't have a way to indicate, from the LB extension, whether we want the locality weights here, since we can't tell simply by inspecting the config. The ideal way to solve this problem, I think, is programatically - have the LB extension indicate whether it wants the locality weights. But I think that would require the logic here to move to something in the load balancing policy, whereas it's currently somewhere enclosed by cluster logic.

Signed-off-by: Eugene Chan <eugenechan@google.com>
@snowp
Copy link
Copy Markdown
Contributor

snowp commented Sep 3, 2021

Seems like a CI failure, can you take a look?

/wait

@pianiststickman
Copy link
Copy Markdown
Contributor Author

/retest

@repokitteh-read-only
Copy link
Copy Markdown

Retrying Azure Pipelines:
Retried failed jobs in: envoy-presubmit

🐱

Caused by: a #17947 (comment) was created by @pianiststickman.

see: more, trace.

Signed-off-by: Eugene Chan <eugenechan@google.com>
@pianiststickman
Copy link
Copy Markdown
Contributor Author

pianiststickman commented Sep 3, 2021

Ha, I didn't realize that CI checked my spelling. PTAL :-)

Copy link
Copy Markdown
Contributor

@snowp snowp left a comment

Choose a reason for hiding this comment

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

Thanks!

@snowp snowp merged commit 63d9858 into envoyproxy:main Sep 3, 2021
@pianiststickman pianiststickman deleted the locality-weights branch September 3, 2021 18:28
tyxia pushed a commit to tyxia/envoy that referenced this pull request Sep 21, 2021
…cing extension (envoyproxy#17947)

`locality_weights` is currently calculated only when the cluster contains
a `common_lb_config` containing a locality weighted config. This allows
load balancing extensions to receive `locality_weights`.

In the future, it might be preferable to have the load balancing policy
indicate, programatically, whether it needs the locality weights, as an
optimization in cases where it doesn't.

This commit also pulls the custom LB used in `CustomStaticCluster` into
its own library so that it can be re-used.

Signed-off-by: Eugene Chan <eugenechan@google.com>

Signed-off-by: pianiststickman <34144687+pianiststickman@users.noreply.github.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.

4 participants