@zuercher in general this seems reasonable to me, but in this case I wonder if it would be useful to see the accompanying code PR to see if the API makes sense. I'm still a little hazy on how the matching is going to happen at decent performance without using reflection.

I don't feel that strongly about it but my preference would be to see a rough draft of the code PR so that we can look at them side by side. We can keep this open and iterate on both if that works for you.

Ok.

See envoyproxy/envoy#1735 for the requested rough draft.

Also, are the subset key lists only a convenience for the purpose of precomputing subsets ahead of time?

Yes, there are choices about how to reconcile overlapping subsets that require more or less overhead. I tried to pick one that was efficient and allowed one to reason about which subset would chosen for a given input.

The subset key lists call out the combinations of metadata keys that are desired for routing. This lets you specify that you might want, for example, to route on stage+version or just version, but not on stage alone. Or as a different example, that you want to route on stage+version and memory_size+version but not other combinations.

Effectively it lets you limit the number of subsets be limiting the possible combinations and lets you ignore certain metadata altogether. (The latter could be achieved by filtering them from the config in the first place.)

Precomputing the subsets ahead of time lets you avoid whatever locking would be necessary if they were done at the point of load balancing. I think that's preferred. We could instead compute the required subsets from the current routes. Eventually, however, I'd like to see a mechanism where the metadata values used for choosing a subset come from a request header. My use case for this is to allow a developer to force their requests to a particular endpoint (e.g., a test version they've deployed) without having to explicitly add routes.

Eventually, however, I'd like to see a mechanism where the metadata values used for choosing a subset come from a request header. My use case for this is to allow a developer to force their requests to a particular endpoint (e.g., a test version they've deployed) without having to explicitly add routes.

I have a lot of thoughts on cool stuff we can do here. See: envoyproxy/envoy#343 for tracking issue.

I think the decisions made here are a good balance of flexibility and runtime performance.

@htuch I'm inclined to merge. Any objections?

Yep, this is great. I think we should capture @zuercher's explanation above for posterity somewhere, I think there's been a lot of thought put into this design that won't be later obvious from just glancing at the API or the implementation details. Up to @zuercher how to do this.

Yeah agreed on docs. I think MD in proxy repo is probably fine but up to @zuercher if he wants to do here.

I'll add some docs tomorrow.

OK, will merge this one for now so we can unblock work on your other PR, look forward to looking at docs.