Open dmi3zkm opened 5 months ago
Update:
After investigation I've found out the reason is the snippet of code below, which is located at https://github.com/solo-io/gloo/blob/main/projects/gloo/pkg/plugins/ratelimit/plugin.go#L119
// projects/gloo/pkg/plugins/ratelimit/plugin.go
func (p *plugin) HttpFilters(params plugins.Params, listener *v1.HttpListener) ([]plugins.StagedHttpFilter, error) {
serverSettings := p.getServerSettingsForListener(listener)
upstreamRef := serverSettings.GetRatelimitServerRef()
if upstreamRef == nil {
return nil, nil
}
// Make sure the server exists
_, err := params.Snapshot.Upstreams.Find(upstreamRef.GetNamespace(), upstreamRef.GetName())
if err != nil {
return nil, ServerNotFound(upstreamRef)
}
The returned err
is appended to the HTTP Listener error report. That's the reason why validator fails the translation.
And that leads me to a question is it always strictly necessary to fail the whole listener if there is no valid rate limit upstream?
Is it a good idea to make this behavior configurable?
Gloo Edge Product
Open Source
Gloo Edge Version
v1.16.9
Kubernetes Version
v1.27.4
Describe the bug
A gateway fails to process any incoming requests after ratelimit/extauth upstream misconfiguration in a
Settings
resource. All requests are affected despite their corresponding route ratelimit/authorization configuration options.Expected Behavior
The gateway should not fail request processing, if no ratelimit/extauth policies applied.
Steps to reproduce the bug
kubectl apply -f https://raw.githubusercontent.com/solo-io/gloo/v1.16.x/example/petstore/petstore.yaml
kubectl apply -f https://gist.githubusercontent.com/dmi3zkm/f85a850bfebb1e63ced67c1c1a177c03/raw/d1ecaea8bf14c1e0fbb4810f1facb516260d77a2/vs.yaml
kubectl apply -f https://gist.githubusercontent.com/dmi3zkm/862d7438e3f634f8546d371ada643ded/raw/b76214b98bb2dde7e424bd44b13b626e8288265a/rl-setup.yaml
Settings
resource.200 OK
Additional Environment Detail
No response
Additional Context
No response