feat(translator): prefix TCP FilterChain name by irListener name

[aoledk]

What this PR does / why we need it:

Prefix TCP FilterChain name by irListener name, to let extension server can locate TCP FilterChain according to policy's targetRef(s).

xref https://github.com/envoyproxy/gateway/issues/3461#issuecomment-2146544345

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 67.91%. Comparing base (8be7e69) to head (562df20). Report is 1043 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3738      +/-   ##
==========================================
+ Coverage   67.89%   67.91%   +0.02%     
==========================================
  Files         187      187              
  Lines       23022    23022              
==========================================
+ Hits        15630    15635       +5     
+ Misses       6278     6273       -5     
  Partials     1114     1114              

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[zhaohuabing]

No strong opinion on the filterchain name, but I think extension server should not make assumption on the structure of the filterchain name or any other names in the xDS. For example, assume the filterchain name will be in the form of "gateway name/listener name/routetype/route name".

This is just an implementation detail of the xDS translation. It's not part of the EG API. There's no guarantee that it won't change over time.

For EnvoyPatchPolicy, it's ok to use these names to find a specified field in the generated xDS, since it's made clear in the EG docs that EnvoyPatchPolicy' is unstable and the outcome may change across versions.

[aoledk]

No strong opinion on the filterchain name, but I think extension server should not make assumption on the structure of the filterchain name or any other names in the xDS. For example, assume the filterchain name will be in the form of "gateway name/listener name/routetype/route name".

This is just an implementation detail of the xDS translation. It's not part of the EG API. There's no guarantee that it won't change over time.

For EnvoyPatchPolicy, it's ok to use these names to find a specified field in the generated xDS, since it's made clear in the EG docs that EnvoyPatchPolicy' is unstable and the outcome may change across versions.

You are correct, this proposal has coupled EG with Extension Server on very unreliable contracts. Perhaps we need to brainstorm other solutions to let Extension Server can detect which FilterChain should be targeted by policies.

Here is a new proposal by @modatwork https://github.com/envoyproxy/gateway/issues/3461#issuecomment-2213410511

[modatwork]

This is just an implementation detail of the xDS translation. It's not part of the EG API. There's no guarantee that it won't change over time.

+1.

However, there is currently no stable method for the extension server to manage the SectionName within the policy API. Can we include this PR in the next release? It’s significant for extensibility.

[arkodg]

can you instead update the IR name https://github.com/envoyproxy/gateway/blob/04c5ce230171ceea261eda354b14538675143614/internal/gatewayapi/helpers.go#L387 ?

[aoledk]

can you instead update the IR name

https://github.com/envoyproxy/gateway/blob/04c5ce230171ceea261eda354b14538675143614/internal/gatewayapi/helpers.go#L387

?

Sure, I can do this since each new ir.TCPRoute or ir.UDPRoute is being attached to unique irListener.

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. Please feel free to give a status update now, ping for review, when it's ready. Thank you for your contributions!

[arkodg]

closing this PR since its become inactive, feel free to reopen if you're still working on it