Benjamin Pineau ea845d3508 gRPC expander: allow realistic server responses, and log errors ... Expander requests' payloads can be rather heavy under upscale pressure, as they're compounding all candidates options and unschedulable pods that could fit each options. Expander responses are a subset of the requests' payload items. We're allowing ourself to send arbitrary payload sizes (gRPC `defaultClientMaxSendMessageSize` is `math.MaxInt32`), but we're prone to drop expander servers responses to the floor, due to the `4MiB` `defaultClientMaxReceiveMessageSize`. The arbitrary 128MiB value is meant to be huge (enough to support eg. several dozen fat 1MiB pods) but not unlimited. Let me know if you'd rather see that turned to be a command line flag, or an other value. Also logging the possible gRPC call errors, as that of great help to diagnose that kind of issues.		2023-01-16 15:40:28 +01:00
..
factory	Make expander factory logic more pluggable	2022-10-12 11:36:12 +02:00
grpcplugin	gRPC expander: allow realistic server responses, and log errors	2023-01-16 15:40:28 +01:00
mocks	Add grpc expander and tests	2022-02-16 12:34:06 -08:00
mostpods	Fix expanders unit tests	2021-09-27 16:00:53 +02:00
price	Fix expanders unit tests	2021-09-27 16:00:53 +02:00
priority	Don't break scale up with priority expander config	2022-10-11 10:52:02 +02:00
random	Allow specification of multiple expanders	2021-09-23 14:31:39 -06:00
waste	Fix expanders unit tests	2021-09-27 16:00:53 +02:00
expander.go	Add grpc expander and tests	2022-02-16 12:34:06 -08:00