Description
I am not sure if this is considered a bug / breaking change or by design
Previous versions of grpc-go checked the existence of XDSBootstrapFileNameEnv = "GRPC_XDS_BOOTSTRAP" at init() but the latest version is creating the xds client pool at init. Which means that previously we could pass an env variable that points to a file and have the program itself construct the config.
The snippet below shows the current behaviour
func init() {
internal.TriggerXDSResourceNotFoundForTesting = triggerXDSResourceNotFoundForTesting
xdsclientinternal.ResourceWatchStateForTesting = resourceWatchStateForTesting
// DefaultPool is initialized with bootstrap configuration from one of the
// supported environment variables. If the environment variables are not
// set, then fallback bootstrap configuration should be set before
// attempting to create an xDS client, else xDS client creation will fail.
config, err := bootstrap.GetConfiguration()
if err != nil {
if logger.V(2) {
logger.Infof("Failed to read xDS bootstrap config from env vars: %v", err)
}
DefaultPool = &Pool{clients: make(map[string]*clientRefCounted)}
return
}
DefaultPool = &Pool{clients: make(map[string]*clientRefCounted), config: config}
}
At init() we call bootstrap.GetConfiguration() and then construct a pool that is invalid because config is a nil.
This is a breaking change because the program here https://gist.github.com/davinci26/4d4a9dcd1e5e7d7842037a438132e813 worked with v.1.70 but does not work with v.1.71
On why we construct the json file in-process is mostly as a convenience factor so we can add the locality field based on the process information.