move serveContext.RequestTimeout into TimeoutConfig and drop old field

[skriss]

Spun out from #2225:

Once this work is complete, we will move the current request-timeout value in the configuration file into this stanza, and add request-timeout-max and request-timeout-min optional parameters that specify the bounds in which HTTPProxy or other objects may configure the timeout. This will be the pattern from now for all timeouts that have Contour-tunable defaults with a HTTPProxy override. This will be done under a separate issue.

[skriss]

Note that per #2697 (comment), the new field will use the standard timeout syntax, which is slightly different from the existing syntax for RequestTimeout. Make sure to call this out in docs.

[jpeach]

Did anyone investigate using an admission controller (e.g. gatekeeper) to enforce this policy? If we add policy controls for every field, configuration will get rapidly out of hand. It's also way better to give policy errors before a resource enters the cluster if possible.

[skriss]

Did anyone investigate using an admission controller (e.g. gatekeeper) to enforce this policy? If we add policy controls for every field, configuration will get rapidly out of hand. It's also way better to give policy errors before a resource enters the cluster if possible.

I did not; I was going off of @youngnick's spec. I can play around with gatekeeper if we're interested.

[stevesloka]

I think you probably still need the validation checks in Contour even with an admission controller. Folks would have to buy into that configuration and it sort of feels like client-side validation where you'd still want the check on the backend.

[skriss]

There are also concerns that an operator who adds new limits has no built-in way of ensuring that they're not going to break existing proxies. It sounds like we need to take a step back here and think more holistically about the design for adding these types of controls. I'm going to close out the associated PR until we get to a consensus on the approach.

[youngnick]

Let's talk about where we go from here and come back around about how we do min/max settings. I agree that my initial ideas about this are not sustainable; we need a more general solution for policy control over settings.

[skriss]

The min/max limits will be implemented via optional Gatekeeper policies.

Leaving this open to track removing the old config file field after a few releases.

[skriss]

I'd like to remove the deprecated field in 1.10 - 3 minor releases after it was deprecated. That sound reasonable to everyone?

[youngnick]

Yes, that's quite reasonable.