Initial Support for Implementation Emitters #262

danehans · 2025-11-19T15:38:43Z

What type of PR is this?
/kind feature

What this PR does / why we need it:

Adds support for implementation emitters, allowing Gateway API implementations to add implementation-specific resources to the list of output resources.
Adds kgateway as an initial implementation emitter.
Adds body buffer feature to ingress-nginx provider (to exercise implementation-specific resources).

Which issue(s) this PR fixes:

Fixes #260

Does this PR introduce a user-facing change?:

Adds implementation emitters. Adds Kgateway as an initial implementation emitter. Adds body buffer size feature to ingress-nginx provider to exercise initial Kgateway emitter implementation.

k8s-ci-robot · 2025-11-19T15:38:49Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: danehans
Once this PR has been reviewed and has the lgtm label, please assign liorlieberman for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Stevenjin8 · 2025-11-19T16:04:18Z

@danehans We still need to debate some details of having implementation specific emitters, but I do want to get some discussion going on the implementation as I've been thinking about this too. I like this PR much more than the last one, but I do have some thoughts on how we want to do this.

There are two points points.

First, I would really want to have all the IR be provider agnostic. Admittedly, the code is not structured this way right now, but from a maintainability POV, having emitters read provider-specific IR is just not tractable as the number of providers and emitters grows. To start, we can have model this IR so its similar to the ingress nginx one.

The second point (that I don't feel as strongly about) is to think about failures as a first class citizen that is embedded into the API. I'm not too sure how this would work, but I have some ideas. Each section of the IR would also have some sort of status. As the emitter parses it, it will write the status saying it was parsed and if there are any caveats the user should know about. That way if we add a new section of IR, they will be parsed as unamrked automatically by all emitters.

I also realize that there is a good amount of urgency to get something working specifically for ingress nginx (I definitely feel it), but if we really want users to use this tool, then I think its worth taking a step back and thinking a bit.

Signed-off-by: Daneyon Hansen <[email protected]>

k8s-ci-robot · 2025-11-19T17:11:23Z

@danehans: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-ingress2gateway-verify	`d088dd2`	link	true	`/test pull-ingress2gateway-verify`

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

danehans · 2025-11-19T17:28:57Z

@Stevenjin8 thanks for the review

First, I would really want to have all the IR be provider agnostic. Admittedly, the code is not structured this way right now, but from a maintainability POV, having emitters read provider-specific IR is just not tractable as the number of providers and emitters grows. To start, we can have model this IR so its similar to the ingress nginx one.

+1 I added the Policy type to IngressNginxHTTPRouteIR, but this could be part of the top-level IR so it's not tied to a specific provider. IMHO refactoring all of the IR to be provider agnostic should not prevent us from proceeding with this PR or some other approach that supports emitting implementation-specific resources. Are you able to work on refacting the IR to be provider agnostic? If so, how long do you anticipate this taking?

The second point (that I don't feel as strongly about) is to think about failures as a first class citizen that is embedded into the API. I'm not too sure how this would work, but I have some ideas. Each section of the IR would also have some sort of status. As the emitter parses it, it will write the status saying it was parsed and if there are any caveats the user should know about. That way if we add a new section of IR, they will be parsed as unamrked automatically by all emitters.

+1 Is this something we can iterate on so we're not blocked by making progress with the foundational work?

LiorLieberman · 2025-11-20T01:25:58Z

@danehans can you please review/engage on https://docs.google.com/document/d/1EJV0nFtcmIK96_4V0C9UV8jlKqjPmmF1MFVfmpF_6lc/edit?tab=t.0

Stevenjin8 · 2025-11-20T18:01:13Z

+1 Is this something we can iterate on so we're not blocked by making progress with the foundational work?

I really think we should figure out the foundational work before we move onto things that rely on the foundation. I don't think this is hard code. So the faster we can get consensus, the faster we can make progress. I'm putting almost all my time into this project right now.

danehans · 2025-11-20T18:54:19Z

xref https://docs.google.com/document/d/1EJV0nFtcmIK96_4V0C9UV8jlKqjPmmF1MFVfmpF_6lc/edit?usp=sharing for discussion related to implementation-specific emitters.

danehans · 2025-11-25T20:27:41Z

Emitters design doc PR xref: #265

Stevenjin8 · 2025-11-25T21:01:02Z

pkg/i2gw/ingress2gateway.go

 		errs = append(errs, conversionErrs...)
+
+		// Convert client.Objects to unstructured and append to GatewayExtensions.
+		for _, obj := range implObjs {


Ok, I was thinking about this but want to get your throughts.

Right now, GCE is the only provider that takes advantage of provider-specific extensions. Do you think that we could have a GCE case and a non-GCE case?

Stevenjin8 · 2025-11-25T21:06:45Z

pkg/i2gw/implementation.go

+
+	// Emit can mutate the IR (e.g. to inject HTTPRoute filters) and returns
+	// implementation-specific objects.
+	Emit(ir *intermediate.IR) ([]client.Object, error)


What do you think of having a ProviderIR and a EmitterIR. ProviderIR would be the current IR (and we could probably shed a bunch of unused fields). It would serve as an initial translation where all the Ingress resources are read without their annotations, the provider would then take that and do things like change certain httproutes to tlsroutes and fill in provider-agnostic data.

Stevenjin8 · 2025-11-25T21:08:35Z

pkg/i2gw/intermediate/provider_ingressnginx.go

 type IngressNginxGatewayIR struct{}
-type IngressNginxHTTPRouteIR struct{}
+
+type IngressNginxHTTPRouteIR struct {


I think we should refactor the way we are doing provider-specific extensions. That is, we should get rid of as many of them as possible. Right now, only GCE uses them and we could keep them around for backcompatibility if we wanted. Ideally, any IR passed to the emitter would have no reference to the provider (or any ingress-related resource).

Stevenjin8

I left these as comments in the code too, but I'll write them again.

My one wish is for the IR fed to the emitter to be provider neutral, and to me, that means having to two IRs, one for the provider and one for the emitter.

The providerIR would be a translation of the Ingress without any implementation specific features and source maps. The providers could, if it wants to, use said IR to flush out the translation and add any provider neutral IR. Then, the emitter would finish the translation.

Stevenjin8

.

Stevenjin8 · 2025-11-25T21:13:52Z

@danehans sorry I thought this was a new PR. Do you still want me to do the provider-neutral emitters. It will probably completely overwrite this PR.

Stevenjin8 · 2025-11-26T19:57:45Z

Here is my (WIP) PR #273

k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Nov 19, 2025

k8s-ci-robot requested review from LiorLieberman and rikatz November 19, 2025 15:38

danehans had a problem deploying to release November 19, 2025 15:38 — with GitHub Actions Failure

k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels Nov 19, 2025

danehans mentioned this pull request Nov 19, 2025

Initial Kgateway Provider Support #261

Closed

danehans force-pushed the impl_emitter branch from 3414acf to 6c5ffb5 Compare November 19, 2025 16:56

danehans temporarily deployed to release November 19, 2025 16:56 — with GitHub Actions Inactive

Initial Support for Implementation Emitters

d088dd2

Signed-off-by: Daneyon Hansen <[email protected]>

danehans force-pushed the impl_emitter branch from 6c5ffb5 to d088dd2 Compare November 19, 2025 17:08

danehans deployed to release November 19, 2025 17:08 — with GitHub Actions Active

Stevenjin8 reviewed Nov 25, 2025

View reviewed changes

Stevenjin8 suggested changes Nov 25, 2025

View reviewed changes

Initial Support for Implementation Emitters #262

Are you sure you want to change the base?

Initial Support for Implementation Emitters #262

Conversation

danehans commented Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

k8s-ci-robot commented Nov 19, 2025

Uh oh!

Stevenjin8 commented Nov 19, 2025

Uh oh!

k8s-ci-robot commented Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

danehans commented Nov 19, 2025

Uh oh!

LiorLieberman commented Nov 20, 2025

Uh oh!

Stevenjin8 commented Nov 20, 2025

Uh oh!

danehans commented Nov 20, 2025

Uh oh!

danehans commented Nov 25, 2025

Uh oh!

Stevenjin8 Nov 25, 2025

Choose a reason for hiding this comment

Uh oh!

Stevenjin8 Nov 25, 2025

Choose a reason for hiding this comment

Uh oh!

Stevenjin8 Nov 25, 2025

Choose a reason for hiding this comment

Uh oh!

Stevenjin8 left a comment

Choose a reason for hiding this comment

Uh oh!

Stevenjin8 left a comment

Choose a reason for hiding this comment

Uh oh!

Stevenjin8 commented Nov 25, 2025

Uh oh!

Stevenjin8 commented Nov 26, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

danehans commented Nov 19, 2025 •

edited

Loading

k8s-ci-robot commented Nov 19, 2025 •

edited

Loading