xds: Distinct LoadStatManagers

[temawi]

Currently the code maintains one LoadStatsManager2 that collects all stats. The problem with this is that in a federation situation there will be multiple LrsClients that will be periodically picking up stats from the manager and sending them to their respective control planes. This creates a first-come-first-serve situation where the stats get randomly distributed across the control planes.

This change creates separate LoadStatsManagers dedicated to their own control planes, thus assuring no stats will get lost.

b/274812461

[temawi]

cc: @larry-safran

[temawi]

While this change assures no stats get missed, it will send all stats for all control planes to every control plane. A possibly more correct approach would be to filter out stats that are not associated with a given control plane, but this could be done as a follow-up.

[larry-safran]

Shouldn't there be null checks on the loadStatsManager since it is now retrieved by a Map.get()?

…

On Tue, Apr 4, 2023 at 11:29 AM Terry Wilson ***@***.***> wrote: Merged #10009 <#10009> into master. — Reply to this email directly, view it on GitHub <#10009 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZQMCXWSCMI7TBWM22DGAHDW7RSATANCNFSM6AAAAAAWSDEK3E> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[temawi]

Shouldn't there be null checks on the loadStatsManager since it is now retrieved by a Map.get()?

As discussed offline, the loadStatsManager is populated in the map when the connection to the control plane is initially set up (in maybeCreateXdsChannelWithLrs()) and since we would only access a loadStatsManager after name resolution has happened (which needs a control plane connection), the map should already been populated for the control plane.