Design ProxySettingsPolicy API

[ciarams87]

As a user of NGF
I want a design to configure NGINX's proxy buffer configuration for my applications through the use of ProxySettingsPolicy
So that I can implement the ProxySettingsPolicy CRD

Design should account for:

• NGINX directives:
  • proxy_buffer_size
  • proxy_buffers
  • proxy_buffering
  • proxy_busy_buffers_size

And be extensible to support further proxy_* directives later

• The NGINX Extensions design is reviewed to implement the above directives.
• The above directives are configurable via a ProxySettingsPolicy for the scope it is applied at.
• The ProxySettingsPolicy can be attached to a Gateway or Route.

Acceptance:
An enhancement proposal is created for the design

[mkingst]

As discussed, we will call the extension NginxProxyConfigPolicy, which will be a declarative way to configure policies specific to NGINX's proxy functionality, such as buffering, timeouts, and more. We will start with proxy_buffer*

Example:

kind: NginxProxyConfigPolicy
metadata:
  name: example-nginx-proxy-policy
spec:
  proxyBufferSize: "8k"
  proxyBuffers:
    number: 4
    size: "16k"
  proxyBuffering: true
  proxyBusyBuffersSize: "32k"

This allows us to add more directives in future (e.g. proxy_connect_timeout, proxy_http_version, etc.)

[sjberman]

NginxProxyConfigPolicy doesn't really follow our existing naming conventions for policies (i.e. we don't prefix with Nginx, and we use Settings in the name) and it sounds too familiar to our current NginxProxy API.

I would suggest something else, maybe ProxySettingsPolicy.

[sjberman]

I would also suggest we try to follow a similar structure and naming for fields like we did with the ClientSettingsPolicy. The body settings were all part of the same struct, so we could do something similar with the buffer settings. I also don't think we should necessarily include proxy in the field names, since that's going to be the prefix for all of them, and we don't follow that pattern for client_ fields in the ClientSettingsPolicy.

Just want to make sure we are consistent across all policies.

[mkingst]

ProxySettingsPolicy is fine. It was the one @ciarams87 and I were going back and forth about. We were worried about it being quite broad with the word "proxy", but if we already have ClientSettingsPolicy, then it makes sense. Let's go with ProxySettingsPolicy then.