Open rinfx opened 4 weeks ago
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 :)
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:
version: pre
, the cluster subset with label version: pre
will be seclectedversion
http request header, envoy will try to get the cluster subset in the dev, pre, prod
order
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 asThen I send a request with dynamic_metadata
version: pre
, however, theversion: dev
will be selected. I think the right order isversion: pre
subsetI would be very grateful if you could answer my question @MarcinFalkowski