AlinsRan commented on PR #2703: URL: https://github.com/apache/apisix-ingress-controller/pull/2703#issuecomment-3894653066
From a Gateway API perspective, `Gateway.spec.listeners[].port` represents the **infrastructure-facing listener configuration** of a Gateway instance. Conceptually, it describes which ports the Gateway exposes externally, rather than acting as a route-level filtering condition. Mapping `listener.port` directly to APISIX `server_port` as a route match condition is technically feasible and pragmatic, especially in the current single-instance deployment model. However, this approach effectively interprets the listener port as a **data plane route constraint**, which slightly shifts the abstraction boundary: * Gateway API intent: infrastructure declaration (listener capability) * Current implementation: route-level match constraint This works well in a shared-instance model (one APISIX instance serving multiple listeners), but may introduce constraints if we later want to: * Instantiate multiple Gateway instances mapped to independent APISIX deployments * Dynamically manage listener ports at the infrastructure level * Decouple Gateway lifecycle from route-level matching logic To balance practicality and future extensibility, I suggest making this behavior configurable (e.g., via a feature gate or controller configuration option). For example: * `enableListenerPortMatch: true` → map `listener.port` to `server_port` match condition (current PR behavior) * `enableListenerPortMatch: false` → do not inject `server_port` match; treat listener.port purely as infrastructure-level metadata This would allow: 1. Backward-compatible and pragmatic default behavior 2. Flexibility for future multi-instance or infra-driven Gateway implementations 3. Clear separation between infrastructure semantics and route matching semantics -- 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]
