johannes-engler-mw commented on PR #2703:
URL:
https://github.com/apache/apisix-ingress-controller/pull/2703#issuecomment-3764045244
Hi again,
I just realized this PR probably adds a breaking change:
The Change
In internal/controller/utils.go, I updated ParseRouteParentRefs to align
with the Gateway API Specification
(https://gateway-api.sigs.k8s.io/api-types/httproute/#attaching-to-gateways).
Specifically, if a Route's ParentRef does
not specify a sectionName, the spec requires it to attach to all
compatible listeners.
My implementation now does exactly this:
1 // internal/controller/utils.go
2
3 // Always add to the list of matched listeners
4 matchedListeners = append(matchedListeners, listener)
5 matched = true
6
7 // Only break if sectionName was explicitly specified
8 if sectionNameSpecified {
9 break
10 }
The Risk
Previously, the controller would stop after the first match. This change
means that if a user has a Gateway with multiple listeners (e.g., public-80 and
internal-8080) and a Route without a sectionName, that Route will now
automatically be exposed on both listeners.
This is technically "correct" per the spec, but for users relying on the
old "first match only" behavior, this could inadvertently expose internal
services to public ports upon upgrade.
Proposal
I believe we should address this to avoid surprised users. I see two main
options:
1. Feature Flag: I can add a flag like enable_legacy_listener_matching
(defaulting to false or true depending on our safety preference) to let users
opt-in to the old behavior.
2. Documentation/Release Note: We explicitly document this as a breaking
change required for Gateway API conformance.
I'm leaning towards option 1 for safety, or at least a very prominent
warning. Let me know your preference and I can update the PR accordingly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
