xds: Allow child of cluster_impl LB to change#10091
Conversation
|
@ejona86 FYI |
Under normal conditions the child LB of `ClusterImplLoadBalancer` does not fluctuate, based on the field used to configure load balancing in the xDS `Cluster` proto it is either: 1. `WrrLocalityLoadBalancer` if the newer `load_balancing_policy` field is used 2. `WeightedTargetLoadBalancer` if the legacy `lb_policy` field is used `ClusterImplLoadBalancer` currently assumes that this child does not change and so does not change the child LB when the name resolver sends an update. If the control plane does switch to using a different field for LB config, that update will have an LB config meant for the other child LB type. This will result in a ClassCastException and a channel panic. To address this, `ClusterImplLoadBalancer` will now use `GracefulSwitchLoadBalancer` and makes sure if the child policy changes the correct LB implementation is switched to.
00995af to
d50d989
Compare
|
Everything looks good except that GracefulSwitchLoadBalancer is marked experimental. Since ClusterImplLoadBalancer isn't, I believe that it isn't supposed to depend on an experimental class. |
|
I've added GracefulSwitchLoadBalancer to the top of the stabilization agenda. |
It's already being used by several other LBs, so I think we can use it here. +1 to your other comment about stabilizing it. |
This is apples and oranges. We can use experimental APIs, because we can change the callers at the same time as breaking the API. That's why it is safe(r) for us to use ClusterImplLoadBalancer is not experimental. The class is not exposed at all. The only way the class would be exposed is via the LB registry, and its name there is also experimental. And the LoadBalancer API itself is experimental. |
ejona86
left a comment
There was a problem hiding this comment.
The rest looks to be the right shape.
Under normal conditions the child LB of `ClusterImplLoadBalancer` does not fluctuate, based on the field used to configure load balancing in the xDS `Cluster` proto it is either: 1. `WrrLocalityLoadBalancer` if the newer `load_balancing_policy` field is used 2. `WeightedTargetLoadBalancer` if the legacy `lb_policy` field is used `ClusterImplLoadBalancer` currently assumes that this child does not change and so does not change the child LB when the name resolver sends an update. If the control plane does switch to using a different field for LB config, that update will have an LB config meant for the other child LB type. This will result in a ClassCastException and a channel panic. To address this, `ClusterImplLoadBalancer` will now use `GracefulSwitchLoadBalancer` and makes sure if the child policy changes the correct LB implementation is switched to.
|
While the problem is explained correctly, the premise is off. There is no alternating between |
Under normal conditions the child LB of `ClusterImplLoadBalancer` does not fluctuate, based on the field used to configure load balancing in the xDS `Cluster` proto it is either: 1. `WrrLocalityLoadBalancer` if the newer `load_balancing_policy` field is used 2. `WeightedTargetLoadBalancer` if the legacy `lb_policy` field is used `ClusterImplLoadBalancer` currently assumes that this child does not change and so does not change the child LB when the name resolver sends an update. If the control plane does switch to using a different field for LB config, that update will have an LB config meant for the other child LB type. This will result in a ClassCastException and a channel panic. To address this, `ClusterImplLoadBalancer` will now use `GracefulSwitchLoadBalancer` and makes sure if the child policy changes the correct LB implementation is switched to.
Under normal conditions the child LB of `ClusterImplLoadBalancer` does not fluctuate, based on the field used to configure load balancing in the xDS `Cluster` proto it is either: 1. `WrrLocalityLoadBalancer` if the newer `load_balancing_policy` field is used 2. `WeightedTargetLoadBalancer` if the legacy `lb_policy` field is used `ClusterImplLoadBalancer` currently assumes that this child does not change and so does not change the child LB when the name resolver sends an update. If the control plane does switch to using a different field for LB config, that update will have an LB config meant for the other child LB type. This will result in a ClassCastException and a channel panic. To address this, `ClusterImplLoadBalancer` will now use `GracefulSwitchLoadBalancer` and makes sure if the child policy changes the correct LB implementation is switched to.
Under normal conditions the child LB of `ClusterImplLoadBalancer` does not fluctuate, based on the field used to configure load balancing in the xDS `Cluster` proto it is either: 1. `WrrLocalityLoadBalancer` if the newer `load_balancing_policy` field is used 2. `WeightedTargetLoadBalancer` if the legacy `lb_policy` field is used `ClusterImplLoadBalancer` currently assumes that this child does not change and so does not change the child LB when the name resolver sends an update. If the control plane does switch to using a different field for LB config, that update will have an LB config meant for the other child LB type. This will result in a ClassCastException and a channel panic. To address this, `ClusterImplLoadBalancer` will now use `GracefulSwitchLoadBalancer` and makes sure if the child policy changes the correct LB implementation is switched to.
Under normal conditions the child LB of `ClusterImplLoadBalancer` does not fluctuate, based on the field used to configure load balancing in the xDS `Cluster` proto it is either: 1. `WrrLocalityLoadBalancer` if the newer `load_balancing_policy` field is used 2. `WeightedTargetLoadBalancer` if the legacy `lb_policy` field is used `ClusterImplLoadBalancer` currently assumes that this child does not change and so does not change the child LB when the name resolver sends an update. If the control plane does switch to using a different field for LB config, that update will have an LB config meant for the other child LB type. This will result in a ClassCastException and a channel panic. To address this, `ClusterImplLoadBalancer` will now use `GracefulSwitchLoadBalancer` and makes sure if the child policy changes the correct LB implementation is switched to.
Under normal conditions the child LB of `ClusterImplLoadBalancer` does not fluctuate, based on the field used to configure load balancing in the xDS `Cluster` proto it is either: 1. `WrrLocalityLoadBalancer` if the newer `load_balancing_policy` field is used 2. `WeightedTargetLoadBalancer` if the legacy `lb_policy` field is used `ClusterImplLoadBalancer` currently assumes that this child does not change and so does not change the child LB when the name resolver sends an update. If the control plane does switch to using a different field for LB config, that update will have an LB config meant for the other child LB type. This will result in a ClassCastException and a channel panic. To address this, `ClusterImplLoadBalancer` will now use `GracefulSwitchLoadBalancer` and makes sure if the child policy changes the correct LB implementation is switched to.
Under normal conditions the child LB ofClusterImplLoadBalancerdoes not fluctuate, based on the field used to configure load balancing in the xDSClusterproto it is either:1.WrrLocalityLoadBalancerif the newerload_balancing_policyfield is used2.
WeightedTargetLoadBalancerif the legacylb_policyfield is used(The premise set here is off, see comment)
ClusterImplLoadBalancercurrently assumes that this child does not change and so does not change the child LB when the name resolver sends an update. If the control plane does switch to using a different field for LB config, that update will have an LB config meant for the other child LB type. This will result in a ClassCastException and a channel panic.To address this,
ClusterImplLoadBalancerwill now useGracefulSwitchLoadBalancerand makes sure if the child policy changes the correct LB implementation is switched to.Closes #10006