EnvoyPatchPolicy with targetRef

[zirain]

1. should we allow to use targetRefs like EnvoyExtensionPolicy?

2. TargetRef to Gateway in MergeGateways mode not working

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyPatchPolicy
metadata:
  name: patch-gateway-class
  namespace: default
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: GatewayClass
    name: eg-merge-demo
  type: JSONPatch
  jsonPatches:
    - name: "default/gateway-v1/http-v1"
      type: type.googleapis.com/envoy.config.listener.v3.Listener
      operation:
        op: add
        path: /default_filter_chain/filters/0/typed_config/http_filters/0
        value:
          name: "envoy.lua"
          typedConfig:
            "@type": type.googleapis.com/udpa.type.v1.TypedStruct
            typeUrl: type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
            value:
              inline_code: |
                function envoy_on_request(request_handle)
                  -- Make an HTTP call to an upstream host with the following headers, body, and timeout.
                  val = request_handle:headers():get("x-envoy-peer-metadata-id")
                  request_handle:logWarn("get result: " .. val)
                end
---
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyPatchPolicy
metadata:
  name: patch-gateway
  namespace: default
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: gateway-v2
  type: JSONPatch
  jsonPatches:
    - name: "default/gateway-v2/http-v2"
      type: type.googleapis.com/envoy.config.listener.v3.Listener
      operation:
        op: add
        path: /default_filter_chain/filters/0/typed_config/http_filters/0
        value:
          name: "envoy.lua"
          typedConfig:
            "@type": type.googleapis.com/udpa.type.v1.TypedStruct
            typeUrl: type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
            value:
              inline_code: |
                function envoy_on_request(request_handle)
                  -- Make an HTTP call to an upstream host with the following headers, body, and timeout.
                  val = request_handle:headers():get("x-envoy-peer-metadata-id")
                  request_handle:logWarn("get result: " .. val)
                end

NAME                  ACCEPTED   PROGRAMMED   AGE
patch-gateway                                 7m5s
patch-gateway-class   True       True         7m5s

patch-gateway was ignored without any information, here are some thinkings:

1. Should EG allow to patch gateway in merge gateways mode?
2. Should EG allow to patch GatewayClass(attached to all the gateways within the GatewayClass) in default mode?

More thinking about this:

The EnvoyExtensionPolicy "lua-extension-policy" is invalid: spec: Invalid value: "object": this policy can only have a targetRefs[*].kind of Gateway/HTTPRoute/GRPCRoute/TCPRoute/UDPRoute/TLSRoute

Should we allow EnvoyExtensionPolicy target to a GatewayClass?

[zirain]

In today's meeting, we discussed this issue:

should we allow to use targetRefs like EnvoyExtensionPolicy?

yes, why not.

TargetRef to Gateway in MergeGateways mode not working

zirain will take the time to see if this is feasible, ListenerSet may have similar question.

[jukie]

One question I have for merge gateway mode is whether there's any limitations around what can be targeted and if it's safe to allow per-gateway targeting. I may be wrong but because they share infra, in certain cases I think targeting gateway A may have impact on gateway B.

[zirain]

One question I have for merge gateway mode is whether there's any limitations around what can be targeted and if it's safe to allow per-gateway targeting. I may be wrong but because they share infra, in certain cases I think targeting gateway A may have impact on gateway B.

that might be true, and we should be careful it we want to support ListenerSet.

And if we believe that ListenerSet is the future, we could allow to target to Gateway only.

[jukie]

ListernerSet is slightly different because it's only a single top-level gateway that exists. For ListenerSets we can differentiate between them and I believe they'll mostly be xDS listener-level settings.

[zirain]

ListernerSet is slightly different because it's only a single top-level gateway that exists. For ListenerSets we can differentiate between them and I believe they'll mostly be xDS listener-level settings.

IIUC, ListenerSet <-> Gateway(in non-merge mode) is more like Gateway <-> GatewayClass(in merge mode).
cc @cnvergence correct me if i'm wrong.

[nishantbkl3345-ship-it]

Thanks for the discussion here.

From what I understand, the main issue was that targeting Gateway in MergeGateways mode was getting silently ignored with no feedback.

This PR just tries to make that behavior explicit so users aren’t left confused.

Happy to change the approach if supporting Gateway targetRef in MergeGateways mode is the preferred direction.

[jukie]

That's not how it works currently

[nishantbkl3345-ship-it]

Got it, thanks for pointing that out.

My understanding was based on the behavior where the policy wasn't getting applied and no status was reported, so I tried to make that explicit.

If I misunderstood how it currently works, I'd appreciate some clarification on the expected behavior for Gateway targetRef in MergeGateways mode.

Also, let me know if there are specific changes you'd prefer here — happy to update the PR accordingly.