Add ResponseHeaderModifier to HTTPRouteFilter

[aryan9600]

What type of PR is this?
/kind feature
/kind api-change

What this PR does / why we need it:
This PR implements GEP-1323. It renames HTTPRequestHeaderFilter to HTTPHeaderFilter and introduces a new field ResponseHeaderModifier in HTTPRouteFilter. It also adds conformance tests for the same.

Which issue(s) this PR fixes:

Relates to #1323

Does this PR introduce a user-facing change?:

A new field `responseHeaderModifier` is added to `.spec.rules.filters`, which allows for modification of HTTP response headers

[k8s-ci-robot]

Hi @aryan9600. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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/test-infra repository.

[shaneutt]

/ok-to-test

[youngnick]

LGTM as long as well are all fine with moving this straight to beta (I vote yes to that).

[youngnick]

Hmm, this line moves this feature straight into beta. It feels like it's probably okay to me, especially with the included conformance tests, but we should probably just be sure we all agree.

[robscott]

Thanks @aryan9600! Mostly LGTM, just want to be sure that this is added as an experimental feature.

[aryan9600]

Moved this feature to experimental for now.

[robscott]

Thanks @aryan9600! This looks really close, just a few more comments.

[shaneutt]

I think this looks solid, and I think it's an interesting addition: it will be interesting to see the usage reporting for this.

I'm approving, but I'll leave the LGTM to @robscott who was previously reviewing.

[robscott]

Thanks @aryan9600!

/lgtm
/approve

[aryan9600]

I'm trying to fix the issues causing CI to fail. It looks like #1390 modifies v1alpha2 to use v1beta1 definitions as aliases. Thus, running make update-codegen with the changes in this PR causes the new field to be added to the v1alpha2 CRD as well, which leads me to believe that // +k8s:deepcopy-gen=false on this line isn't actually working as intended.

gateway-api/apis/v1alpha2/httproute_types.go

Line 239 in 544d916

// +k8s:deepcopy-gen=false

I could manually remove it but then this would need to be done every time someone runs make update-codegen, so I'm kinda unsure on how to proceed. cc: @howardjohn @robscott

[robscott]

Hey @aryan9600, this was a tricky one. From what I can tell, it requires a rebase on the main branch + the following changes:

--- a/apis/v1alpha2/grpcroute_types.go
+++ b/apis/v1alpha2/grpcroute_types.go
@@ -427,7 +427,7 @@ type GRPCRouteFilter struct {
        // Support: Core
        //
        // +optional
-       RequestHeaderModifier *HTTPRequestHeaderFilter `json:"requestHeaderModifier,omitempty"`
+       RequestHeaderModifier *HTTPHeaderFilter `json:"requestHeaderModifier,omitempty"`

        // RequestMirror defines a schema for a filter that mirrors requests.
        // Requests are sent to the specified destination, but responses from
diff --git a/apis/v1alpha2/httproute_types.go b/apis/v1alpha2/httproute_types.go
index dfbabce..62ff375 100644
--- a/apis/v1alpha2/httproute_types.go
+++ b/apis/v1alpha2/httproute_types.go
@@ -292,10 +292,10 @@ const (
 // +k8s:deepcopy-gen=false
 type HTTPHeader = v1beta1.HTTPHeader

-// HTTPRequestHeaderFilter defines configuration for the RequestHeaderModifier
-// filter.
+// HTTPHeaderFilter defines a filter that modifies the headers of an HTTP request
+// or response.
 // +k8s:deepcopy-gen=false
-type HTTPRequestHeaderFilter = v1beta1.HTTPRequestHeaderFilter
+type HTTPHeaderFilter = v1beta1.HTTPHeaderFilter

After these changes, code generation appeared to work well for me locally.

[aryan9600]

@robscott i don't think that'll work, since the problem arises due to

gateway-api/apis/v1alpha2/httproute_types.go

Line 240 in 544d916

type HTTPRouteFilterType = v1beta1.HTTPRouteFilterType

since v1beta1.HTTPRouteFilter contains the new field responseHeaderModifier, v1alpha2.HTTPRouteFilter now also contains this new field, leading to the codegen making it a part of v1alpha2 CRD.
I think we need a way to disable codegen for the v1alpha2 CRD, so that any changes to the codebase from that commit onwards doesn't affect the CRD. wdyt?

[robscott]

since v1beta1.HTTPRouteFilter contains the new field responseHeaderModifier, v1alpha2.HTTPRouteFilter now also contains this new field, leading to the codegen making it a part of v1alpha2 CRD.

@aryan9600 I get the confusion now. That's actually exactly what we want to happen. It's not well documented, but standard practice with k8s APIs is to add all new fields to all supported API versions. In upstream Kubernetes, new fields are hidden with feature gates and are opt in. Since Gateway API is using CRDs, we came up with the parallel concept of an "experimental" release channel that gets new fields first. With that said, whether you're using CRDs from the experimental or standard release channel, both of the API versions contained within them should have an identical set of fields.

[aryan9600]

@robscott got it, i was under the impression that we want the new field in the latest API version only. thanks for clarifying :)

[robscott]

Thanks @aryan9600!

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: aryan9600, robscott, shaneutt

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [robscott,shaneutt]

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