Feature Request: add haproxy filters to Frontend

[git001]

I would like to add the filter feature into HUG.
Is anybody already working on this?
Is this an PR which would be accepted?

I have pushed the features in that branch https://github.com/git001/haproxy-unified-gateway/tree/feature/fe-filters

The reason behind that feature is to be able to create and rate filter and global rate filter similar to envoy's rate limiting options https://github.com/envoyproxy/ratelimit

[oktalz]

hi @git001
similar to what you did
we do have plan add full support for Frontend CRD, but currently we are still in design phase of this.

one of concerns currently is to determine how to 'merge' / 'override' multiple gateway CRDs,
should we even do it or just add Frontend CRD to virtual one etc ...

also idea is to allow full customizability (override/append for things that HUG manages), so any kind of custom design should be possible too.

Internally we have some larger reorganization of how we deal with maps (GWAPI conformance tests do not really follow spec :( )
after we merge that (should be next week)

Is this an PR which would be accepted?

yes, it could be, but I will have time to take a look at it next week

[git001]

Hi @oktalz , thank you for your response.
I think then to wait for the next step after the design phase is finished.

Regards #20 will the be also considered in the design phase especially that the TCPRoute is part or the spec, more or less 😄

[hdurand0710]

Hi @git001

Thanks for your contribution.
This MR defines a Frontend CRD that links to 0 or 1 Gateway, and the content (Filters) are applied to all (if 0 parentRef) or all listeners of the Gateway (if 1 parentRef).

Ideally, we think that there is a need to have different CRDs (different Filters...) per Frontend, be able to apply specific settings (Filters) for each Frontend.

As several Gateway listeners can be merged into the same Frontend (there are grouped in the code as VirtualListeners, 1 Frontend = 1 VirtualListener), we need to be able to define a CRD per VirtualListener.

Note that several Listener in different Gateways can end up being the same VirtualListener. Merging Listeners into 1 VirtualListener is not restricted to the listeners among the same Gateway but can happen between several Gateways.
We then end up with what @oktalz was describing in terms of merging/overriding/reject with conflict (and in which order ? ).

We did not reach the final design phase on all those questions and are left with 2 main options:
Option 1: your approach enhanced with adding the listener name to the parentRef to be able to have different CRDs (Filters/...) per frontend. Here we need to decide between merge/override/conflict/order for all CRDs that would end up being the same VirtualListener, so the same Frontend.
Option2: Find a way to define a VirtualListener CRD that would then really apply to only 1 haproxy Frontend.

2nd step would be as @oktalz was mentionning to add a full Frontend support but this can be done after your step of adding Filters, once the previous design choices have been made.

We did not reached for now a conclusion between option 1 and option 2 and did not have time to make much progress on this.

We would be very interested in having your feedback on the design choices.
Then if you have time to work on this MR to update to option 1 or option 2 (or other idea you would have), that will be really appreciated.