shreemaan-abhishek commented on PR #2810: URL: https://github.com/apache/apisix-ingress-controller/pull/2810#issuecomment-5114385835
Agreed on the direction — thanks for the detailed writeup. You're right on the two points that matter: admission rejection is incomplete (it can't see a conflict introduced by a certificate rotating inside its Secret, a GatewayProxy/IngressClass regrouping, a disabled webhook, or an object created before the webhook existed), and it's a backward-compatibility break (an unrelated edit to an object that already coexists with an overlapping one gets rejected). And overlapping SNIs are what Gateway API says to admit-and-report, not deny. I've pushed a change so the detector now emits an admission **warning** instead of denying, on both `ValidateCreate` and `ValidateUpdate`. The detection itself — wildcard/exact overlap and the mTLS client-config dimension — stays, so the warning is accurate; the data plane behavior is unchanged, as you noted. The fuller treatment you describe — detect on **reconcile**, set an `OverlappingTLSConfig`-style status condition on the affected objects, with the documented tie-break (longest SNI, then oldest `creationTimestamp`, then `namespace/name`) — is a larger change; I'd like to take it as a tracked follow-up rather than grow this PR. Does splitting it that way work for you? One clarification for context: reject-at-admission predates this PR. This change extended what the detector notices (wildcard overlap + mTLS config) and now moves the response from deny to warn. -- 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]
