Is it ok to use outlierdetection load balancer without xds?

[s-matyukevich]

I built a small prof-of-concept and run and configured the outlier detection load balancer by passing a json-serialized service config with the schema taken from here and importing "google.golang.org/grpc/xds" package. Everything works fine, but I have some concerns/questions about this approach:

• Are you going to eventually move outlierdetection LB to a public package and keep it non xds specific? Based on this I assume this is the case, but I want the maintainers to confirm.
• The loadbalancer implementation is still experimental, so I assume there is high chance that there will be non backward-compatible changes to the config schema in the future. Is that correct?
• We are ok with handling non backward-compatible changes during upgrades, but we don't want our code to silently fail or change behavior in unexpected ways. If we build the LB config schema directly from grpc-proto, is it going to protect us from such things? Anything else we should do?

[easwars]

@zasweq

Are you going to eventually move outlierdetection LB to a public package and keep it non xds specific? Based on this I assume this is the case, but I want the maintainers to confirm.

Yes, you are right. We do plan to move it out of the xDS tree and de-experimentalize the balancer at some point.

The loadbalancer implementation is still experimental, so I assume there is high chance that there will be non backward-compatible changes to the config schema in the future. Is that correct?

I wouldn't say there is a high chance of non backward-compatible changes to the schema. But there is definitely some chance.

We are ok with handling non backward-compatible changes during upgrades, but we don't want our code to silently fail or change behavior in unexpected ways. If we build the LB config schema directly from grpc-proto, is it going to protect us from such things? Anything else we should do?

The LB config schema defined in the grpc-proto repo is the canonical source of truth. But the grpc-go repository does not have a dependency on the service_config.proto, as our LB policies accept configs in JSON.

Whenever we intend to make a change to the LB config schema, we would send out a proposal in our proposal repo, followed by changes to the grpc-proto repo and then followed by changes to the individual grpc language repos. Barring unforeseen circumstances, most schema changes would be done in a way that doesn't break older versions of the code.

Hope this helps.

[s-matyukevich]

Thanks, @easwars this is helpful.