Problem
The nvcf-gateway-routes chart installs a ValidatingAdmissionPolicy that reserves each enabled chart route's hostname for a single owning HTTPRoute. Any other HTTPRoute claiming that hostname on the shared Gateway listener is denied on create and on update, regardless of its path match.
Gateway API permits several HTTPRoutes to share a hostname and resolves them by rule precedence: exact path, then longest path prefix, then method match, then header count, then query count. Only when all of those tie does resolution fall through to the creation timestamp, and that fall-through is the silent, unobservable outcome the policy was added to prevent.
The self-managed stack itself ships such a pair. helm-admin-token-issuer-proxy renders an HTTPRoute on api-keys.<domain> with PathPrefix /v1/admin/keys, alongside the chart-owned api-keys route on PathPrefix /. The longer prefix wins deterministically, and the pair has served traffic correctly since before the policy existed. Because the policy only evaluates CREATE and UPDATE, both routes are grandfathered until something touches them, at which point the admin route's patch is denied:
cannot patch "admin-token-issuer-proxy" with kind HTTPRoute:
httproutes.gateway.networking.k8s.io "admin-token-issuer-proxy" is forbidden:
ValidatingAdmissionPolicy '...' denied request: hostname "api-keys.<domain>"
is reserved by NVCF HTTPRoute "<gateway-ns>/api-keys" ...
helmfile then stops the remaining releases in the DAG. The only workaround is to delete the cluster-scoped ValidatingAdmissionPolicyBinding, apply, and restore it, which leaves HTTPRoute admission unguarded cluster-wide in between.
Fresh installs happen to work only because admin-issuer-proxy sorts into an earlier helmfile DAG layer than ingress, so the route is created before the policy exists. Nothing enforces that ordering, and if it changes the admin token issuer gets no route at all.
Expected
An HTTPRoute whose match is ordered deterministically against the owning route by Gateway API precedence is admitted. Only a match that ties the owner, and therefore resolves silently by creation timestamp, is rejected.
Problem
The
nvcf-gateway-routeschart installs aValidatingAdmissionPolicythat reserves each enabled chart route's hostname for a single owningHTTPRoute. Any otherHTTPRouteclaiming that hostname on the shared Gateway listener is denied on create and on update, regardless of its path match.Gateway API permits several
HTTPRoutes to share a hostname and resolves them by rule precedence: exact path, then longest path prefix, then method match, then header count, then query count. Only when all of those tie does resolution fall through to the creation timestamp, and that fall-through is the silent, unobservable outcome the policy was added to prevent.The self-managed stack itself ships such a pair.
helm-admin-token-issuer-proxyrenders anHTTPRouteonapi-keys.<domain>withPathPrefix /v1/admin/keys, alongside the chart-ownedapi-keysroute onPathPrefix /. The longer prefix wins deterministically, and the pair has served traffic correctly since before the policy existed. Because the policy only evaluates CREATE and UPDATE, both routes are grandfathered until something touches them, at which point the admin route's patch is denied:helmfilethen stops the remaining releases in the DAG. The only workaround is to delete the cluster-scopedValidatingAdmissionPolicyBinding, apply, and restore it, which leavesHTTPRouteadmission unguarded cluster-wide in between.Fresh installs happen to work only because
admin-issuer-proxysorts into an earlier helmfile DAG layer thaningress, so the route is created before the policy exists. Nothing enforces that ordering, and if it changes the admin token issuer gets no route at all.Expected
An
HTTPRoutewhose match is ordered deterministically against the owning route by Gateway API precedence is admitted. Only a match that ties the owner, and therefore resolves silently by creation timestamp, is rejected.