Currently, the policy controller's index component is written with HTTPRoute support (effectively) exclusively, both in its structure/organization as well as its naming (e.g. HttpRoute as a primary type name, convert_http_route as a method name, etc...).
In order to expand the subset of route types defined by the Gateway API that linkerd supports for driving inbound traffic policy, the policy controller's inbound index component needs to be made more generic in both respects.
PR introduces structural and naming changes making the codebase generic with respect to the type of route being handled (e.g. HTTPRoute -> Route). Changes are almost entirely cosmetic but may still appear rather extreme at first glance. Even so, PR should not be introducing any meaningful behavioral changes in refactored functions and methods.
Subject
Prepare to expand the subset of
Gateway APIroute typeslinkerdsupports driving outbound traffic with inlinkerd-policy-controller-k8s-index.Problem
Currently, the policy controller's
indexcomponent is written withHTTPRoutesupport (effectively) exclusively, both in its structure/organization as well as its naming (e.g.HttpRouteas a primary type name,convert_http_routeas a method name, etc...).In order to expand the subset of route types defined by the Gateway API that
linkerdsupports for driving inbound traffic policy, the policy controller's inboundindexcomponent needs to be made more generic in both respects.Solution
PR introduces structural and naming changes making the codebase generic with respect to the type of route being handled (e.g.
HTTPRoute->Route). Changes are almost entirely cosmetic but may still appear rather extreme at first glance. Even so, PR should not be introducing any meaningful behavioral changes in refactored functions and methods.Validation
FixesLays Groundwork For Addressing12404