Honestly I don't know why we warn on deprecated config at all given plans to never rev versions again
cc @adisuissa @envoyproxy/api-shepherds
If it's causing problems I'd send out a PR and see if folks object.

I don't think we want to un-deprecate max_grpc_timeout, since my recollection is that it's basically broken from the perspective of gRPC timeout semantics. @dfawley or @ejona86 may remember the details here.

RE un-deprecation - I'm not sure that it is the right thing to do (but we'll need to look at the details before suggesting a path forward).

RE logging - as deprecated fields will probably be supported indefinitely, it may make sense to reduce the logging frequency to once or every N seconds.

#12578 has the context for the old timeout field. tl;dr it's different from how gRPC internally behaves because it only starts when the client closes its sending side of the stream.

How about introducing a new runtime flag that controls whether deprecated features should be logged or not?

How about introducing a new runtime flag that controls whether deprecated features should be logged or not?

I'd suggest adding a bootstrap knob that controls that (because runtime flags are intended to be temporary, and bootstrap knobs are more permanent).

Fair point. We will change it like that

Could you please review this #37407, which provides an option to suppress deprecated warning logs using a command-line option, and provide your feedback.