cmp.Equal is not supposed to be used in production code because of its
propensity towards panicking.
This equality will eventually be checked from the LB policy when it gets
a service config update.
This change only renames the type and reformats some comments. No change
in functionality. The rename was deemed necessary once I started
implementing the balancer and wanted to be consistent. The builder is
named `rlsBB`, the balancer is named `rlsBalancer`, so the picker should
be `rlsPicker`. Also, this rename allows the field in the balancer which
caches the last picker to be named `picker`.
1. Store the RLS server name (lookupService field) as a string instead
of as a resolver.Target as this is passed to grpc.Dial when creating
the control channel.
2. Store the default target specified in the ServiceConfig in a field in
the lbConfig struct.
3. Move some constants defined in builder.go to config.go because they
are only used in the latter.
* Add a Resize method which will be invoked by the RLS LB policy when it
receives a new cacheSize in its ServiceConfig.
* Change the size fields in the cache to int64. This is the type of the
cacheSize field in the proto.
* Store the BackoffState field in the cache.Entry by value instead of as
a pointer because it doesn not buy us much (the backoff state is not
shared between the data cache and the pending cache).
Before this change, in EDS balancer, child balancer's state update is handled synchronously, which includes priority handling. This would cause a deadlock if the child policy sends a state update inline when handling addresses (e.g. when roundrobin handles empty address list).
This change moves the child balancer state handling into a goroutine, to avoid the problem.
- More logs in xds bootstrap/resolver/cds/eds
- Bootstrap file content/error
- Request/response on ADS stream
- Actions by client/resolver/balancer
- Content of updates
- Logs prefixed with component name and id
- `[xds-bootstrap]`
- `[xds-client <address>]`
- `[cds-lb <address>]`
- `[eds-lb <address>]`
- The LRS client will find known clusters from the response, and send the loads
- The LRS client support only one cluster now, will be extended to support multiple
This can happen when the xds ClientConn is in transient failure (a
config error on the server address or creds, or a connection error).
When this happens, the new watches should still be handled, and should
be notified of failure when timeout.
