Even with the hard-stop-after option in place, after 4.7.9 upgrade, the customer was still seeing pod OOM errors.  They have removed the option since then to see if stability would improve, but still the same.

Regarding the HAproxy OOM issue, the customer wants us to be see if we can reproduce this at scale and simulate using a similar number of backends used by them in DEV.  They still aren't convinced that tweaking timeouts on routes, etc is the appropriate way to address this especially since these routes were all configured this way in 4.6.  This increase in haproxy memory consumption only started once they upgraded to 4.7.