Alternative to GRPC_XDS_BOOSTRAP env variable

Goal

I’m looking into creating a utility function that can dynamically create and assign the xDS bootstrap. This could be hooked into the application startup so that xDS can be configured across different environments (IDE, GCE, GKE) without the need of startup shell scripts etc.

While almost every programming language supports dynamically setting environment variables, Java does not. Would it be possible to have an alternative way in java to provide the location of the bootstrap file?

Possible solution

One possible solution that doesn’t break the existing API and gRPC spec would be to also try reading e.g. a java system property (System.getProperty(“grpc.xds.bootstrap”)😉 at https://github.com/grpc/grpc-java/blob/beb3232c0a6c2873292da7d24fb9f678a7f5a650/xds/src/main/java/io/grpc/xds/Bootstrapper.java#L57-L61 In the case that the GRPC_XDS_BOOSTRAP environment variable isn’t found.

Maybe something as simple as:

private static final String BOOTSTRAP_PATH_SYS_PROPERTY_VAR = "grpc.xds.bootstrap";
.
.
.
String filePath = Optional.ofNullable(System.getenv(BOOTSTRAP_PATH_SYS_ENV_VAR))
                          .orElse(System.getProperty(BOOTSTRAP_PATH_SYS_PROPERTY_VAR)); 

Alternatives

Alternative solutions would most likely require larger changes to the existing classes in order to pass the config down.

[srini100]

I guess it would be even nicer to be able to provide the bootstrap config directly to gRPC without the need of a temporary json file, but that’s maybe stretching it a bit too far, since no other grpc implementation would have such a feature and it may require exposing some internals that might change later on.

We should consider this. Istio uses PROXY_CONFIG env variable for bootstrap config without using a file. It is good to have an option that doesn’t require a file to be mounted.

[erikjoh]

As for the priority, my spontaneous thought is that the env variable should have higher prio so that all existing gRPC proxyless documentation still would apply without edge cases. I imagine that a developer might want to learn about proxyless gRPC and follow the official documentation. If the java property took precedence and they used a service framework that internally sets that property and creates the file then they might waste some thought cycles trying to figure out “why it didn’t work as they thought”. But if there are other scenarios that can motivate why the property should take precedence I think that’s fine as well since we could just ignore setting the property if the env variable is set 🙂