Gateway API v0.5.0 API Review

[robscott]

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

What this PR does / why we need it:
This PR represents the diff between v0.4.x and a proposed v0.5.0. This was accomplished by copying the apis/v1alpha2 from master to a branch based on the release-0.4 branch.

Current status

We believe GatewayClass, Gateway, and HTTPRoute have met the criteria we defined earlier for graduation to beta (details). The following work is still in progress:

• Adding new conditions to HTTPRoute status
• A variety of documentation updates and webhook deployment cleanup

Changes from v0.4

The proposed API is largely identical to what we released in v1alpha2, with the following exceptions:

1. We want to graduate GatewayClass, Gateway, and HTTPRoute to v1beta1 (More Details)
2. We have introduced a new "release channels" concept. The new "experimental" release channel allows us to add new features to Gateway API in a similar way to how we use alpha feature gates in upstream to guard new fields initially. (More Details)

New experimental features

There are 3 new experimental features included in this change:

• Path redirects and rewrites GEP 726
• Address matching on TCPRoute and UDPRoute GEP 735
• Port matching in ParentRef GEP 957

Future port changes

As a follow up to the previous review, there has been a lot of discussion around Ports, and potential for port ranges, all ports, and auto assignment:

• All Ports and Port Ranges
• Optional Listener Port
• L4 Gateway Sharing

At this point, we believe that all of the above can be added in the future with backwards compatible changes/additions. Note: this is not saying we should or will make these additions, just that they will still be possible after graduating to beta.

Goals of this review

Since we're an official Kubernetes API, we need formal approval for this change from SIG-Network API Reviewers, assigned below. Of course feedback from others is also welcome here. Our goal is to complete this process by mid to late April.

Note: The aim is not to merge this PR, just to provide a way to review what has changed between v0.4 and v0.5.

/assign @danwinship @khenidak @thockin

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: robscott

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]

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

[thockin]

IPv4, IPv6, hostname are unambiguously parseable (with some effort) - is this justified?

If we want to keep this, should it follow the same 1-field-per enum value pattern?

[robscott]

I think it's at least possible that we'd add additional types in the future that may not be as easy to differentiate between. Even with named address, it's possible that in some systems, a name is just a number, or a name is a valid hostname, or something else. I could get on board with the 1-field-per enum pattern here though.

[danwinship]

The proposed API is largely identical to what we released in v1alpha2, with the following exceptions:

1. We want to graduate GatewayClass, Gateway, and HTTPRoute to v1beta1 (More Details)

I see no references to "v1beta1" here... I had assumed when I read this that you'd be duplicating the "graduating" parts of apis/v1alpha2/ into a new apis/v1beta1/, so that people using only beta APIs could do

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
...

[youngnick]

@danwinship I think that's the plan for actually cutting the release, but I think that @robscott felt this review would be easier if you didn't need to review files that were just all added lines (since a v1beta1 would be net-new and not produce a useful diff.)

The plan is absolutely to take the three resources mentioned and copy them into a v1beta1 version however.

[robscott]

@danwinship Good point, I can make a separate PR with /apis/v1beta1, I was just trying to make it as easy as possible to see what was actually changing. The new v1beta1 types will be identical to the v1alpha2 types shown here, so I'd hoped just seeing a diff covering the current state with what you'd currently reviewed would be more manageable. Let me know if adding /apis/v1beta1 at this point would be helpful.

[youngnick]

Looks like this got closed in error?

[danwinship]

/unassign
(I skimmed over it, but I haven't used this API at all, or thought about it since the last review, so I don't know the context of most of these changes, etc. None of it seems obviously wrong...)

[candita]

@robscott looks good to me, as someone new to the review. I just had a few nits and minor comments.

[thockin]

Discussed in real-time - couple small followups Rob noted. LGTM. Thanks.

[youngnick]

So, I think that once we resolve #1200, #1201, and #1202, we can close this out as complete?

[thockin]

SGTM

…

On Thu, Jun 9, 2022 at 10:07 PM Nick Young ***@***.***> wrote: So, I think that once we resolve #1200 <#1200>, #1201 <#1201>, and #1202 <#1202>, we can close this out as complete? — Reply to this email directly, view it on GitHub <#1086 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKWAVCWZYWUYSYWPJOABJDVOLEP3ANCNFSM5SQZ3O5Q> . You are receiving this because you were assigned.Message ID: ***@***.***>

[evankanderson]

It looks like the three mentioned issues were closed out.

Should this stop being a draft PR?

[youngnick]

Yes, I think we may just close this out - this is really a placeholder to give the API reviewers an easier time. Unless there's something else @robscott wants to do here?

[robscott]

Yep, I think this was good to go. All the changes reviewed here were released as part of v0.5.0-rc1.