The previous 'git ls-remote' was returning the tag-referenced commits via
vF.O.O^{} which was confusing the version check (as v1.30.0 would not match
v1.30.0^{}). Passing --refs filters those ^{} tags.
There was also a missing 'v' in the version check. It was added explicitly to
generate the list but not to check the result.
The routing LB policy should immediately the Channel's picker that delegates picking to the updated routes. Otherwise, new RPCs will keep being sent through old routes even if they are removed. This change also includes the fix for syncing state change for child balancers in deactivated state.
- Add support for send_all_clusters field in LRS response. When it is set to true, just send load reports for clusters that the client is currently tracking (aka, is sending load to).
- The actual load report interval (in each ClusterStats message, which contains the stats for each cluster:eds_service) should be tracked individually.
The top-level LB policy, which is an aggregator for CDS policies. It maintains the lifecycle of CDS LB policy instances. The pick argument taken from the Channel contains the information to determine which child CDS policy instance should the picking operation be delegated to.
The implementation is similar to the action part of what we currently have in the routing policy. The existing routing policy will be refactored to two parts, with the route match part moved into ConfigSelector and action part being this top-level LB policy.
We found that the interceptor approach for `ConfigSelector` would be adding a layer of indirection for no gain: The API Result selectConfig(LoadBalancer.PickSubchannelArgs args) consumes headers among other inputs, because route matching might need to match the headers; and the API produces ClientInterceptor among other outputs. But the headers is not available until clientCall.start(listner, headers), whereas the interceptor need be applied to the call before clientCall.start(). So the input is not available until the output is applied. That means we will need to delay calling the downstream newCall() (which will either be RealChannel or the interceptor) until start() is called.
So we want to change to the other approach similar to what c-core is taking: Have `Result(Object config, CallOptions, Runnable committedCallback)`, where CallOption is the selector modified CallOption, and committedCallback is used to monitor the call lifecycle.
'runtime' is the old classpath, pre-java-library plugin. We could swap to
'runtimeClasspath', but it is cleaner to just use startScript's defaults. We
already use that approach in interop-testing.
Fixes#7218
This prevents grpc-xds and its transitive dependencies from being included
twice in distTar and distZip, which reduces the size from 60 MB to 40 MB. It
does mean that interop-testing as a whole depends on xds, but that should not
be an issue any longer. It was an issue before we started providing grpc-xds on
Maven Central.
This should avoid messages being leaked when a Listener throws an exception and
the executor is shut down immediately after the call completes. This is related
to #7105 but a different scenario and we aren't aware of any user having
observed the previous behavior.
Note also this does _not_ fix the similar case of reordering caused by
delayedCancelOnDeadlineExceeded().
Continuation of #7169 to parse all resources in ADS response to v3 objects. In this PR we still only send v2 requests to xDS server (No v3 bootstrap or env flag support).
This is part of xDS v3 support as per go/grpc-xds-v3-support
In this PR:
- still only send v2 requests to xDS server (No v3 bootstrap or env flag support)
- parse Listener update as v3 proto
- Refactor SDS's Listener watcher to use enovy v3 API
- still parse other resources as v2 proto.
This avoids the "changes" description, which could be understood to mean that
the transition is important instead of the steady-state and thus a callback
might not be called (which is not the case).
Much of the language was copied from ServerCall.
It has been our intention for years to remove nameResolverFactory. We should
make it clear to users to avoid new code depending on it and so they can tell
us why they need it so we can provide replacements.