Why not try to get a matched subset first?

[rinfx]

https://github.com/envoyproxy/envoy/blob/4dd017e89eace3b9aa6a54cfcb5d9d240d73cce6/source/extensions/load_balancing_policies/subset/subset_lb.cc#L185-L199

In this code, the fallback_list takes precedence over exact matching subset.

Assume the following scenario:

There are three subset, version: prod, version: pre, version: dev, and I set a fallback_list such as

fallback_list:
- version: dev
- version: pre
- version: prod

Then I send a request with dynamic_metadata version: pre, however, the version: dev will be selected. I think the right order is

1. try to find a host in version: pre subset
2. if no host found, then try to find host according to the fallback_list

I would be very grateful if you could answer my question @MarcinFalkowski

[MarcinFalkowski]

Hi, could you provide more details, how your final route/dynamic metadata looks like? You said you send a request with version: pre dynamic metadata, so without fallback_list?

Or maybe the metadata you send looks like this?

version: pre
fallback_list:
- version: dev
- version: pre
- version: prod

Also forgive me if what I said doesn't make sense, I haven't been in touch with this mechanism for a long time. I may need some time to remember all this. But we will get there :)

[rinfx]

Thanks for your reply, I think your business scenario is to solve the service degradation problem, while my scenario is to do service grayscale routing first and then downgrade.

I tried to modify the code as follows:

The modified code logic is as follows:

1. If there is an http request header version: pre, the cluster subset with label version: pre will be seclected
2. If no version http request header, envoy will try to get the cluster subset in the dev, pre, prod order