Align logic for reverting a warming cluster and reverting a warming listener
- Dominant language
- C++
- Stars
- 28.9k
- Forks
- 5.6k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 437
Description
*Title*: Align logic for reverting a warming cluster and reverting a warming listener
*Description*:
#15269 fixed blocking a revert of a warming cluster by always accepting a new cluster when it's different from the existing warming cluster. This turns out to be a different approach from #12645 which instead removes the warming listener.
It seems they could both use the same logic for this situation and so probably should. My reasoning for #15269 was that it avoids needing a concept of "reverting" config and it settles at the latest `version_info` given. While #15269 seems simpler, are there advantages to #12645 other than being a performance optimization?
Implementation note: When I tried to adapt the listener manager to use the same logic as #15269 and adjust the unit test `UpdateActiveToWarmAndBack`, `expectListenerOverridden` can't handle this case because `buildFilterChain` and thus `createNetworkFilterFactoryList` aren't called (the existing filter chain is used instead)...
*Relevant Links*:
See https://github.com/envoyproxy/envoy/pull/15269/files#r592046281 for discussion
cc @htuch @adisuissa @dmitri-d
Contributor guide
Assessment
This issue has not been assessed yet.