v1.2 Release Scoping: Features Graduating to Standard

[robscott]

This discussion is similar to #3103, but somewhat simpler. We'll track every GEP that could potentially graduate to standard in this release, and then look for owners to volunteer to drive them forward. Each top level comment will describe a GEP + what is required to take it to standard. To volunteer as a lead for that GEP, please add a comment in the thread below the GEP description.

As a reminder, each GEP that graduates to standard creates a new slot for a GEP to graduate from experimental (#3103), so if you really want a new experimental feature, volunteering to lead an experimental feature to standard will help.

Note that inclusion in the list below is not a guarantee that a GEP will graduate in v1.2, just an acknowledgement that it theoretically could with sufficient effort and consensus.

[robscott]

Timeouts (#1742) and Duration format (#2257).

Status:
Conformance: Complete
Documentation: Complete
Implementations: ?/3

Work Required:

• Survey implementations to ensure we have enough (3+) and/or encourage more implementations to support this feature.
• Updates to GEP, docs, and API types to bump status to standard.

Previous Leads:
@kflynn and @frankbu helped get these to experimental.

[kflynn]

I can take these two. 🙂

[robscott]

GatewayClass Supported Features (#2162)

Status:
Conformance: N/A
Documentation: Not Started
Implementations: ?/3

Work Required:

• Survey implementations to ensure we have enough (3+) and/or encourage more implementations to support this feature.
• Determine if we need more structured format here such as grouping by resource and status (for example HTTPRoute.Experimental, HTTPRoute.Extended)
• Write documentation
• Updates to GEP and API types to bump status to standard.

Previous Leads:
@LiorLieberman has led this effort.

[dprotaso]

Presumably we could go out with the flat format and then change if we later need to...

I don't have a preference but you could change it now to support future extensibility by changing it from a list of strings to a list of maps

eg.

supportedFeatures:
- HTTPRouteHostRewrite
- HTTPRouteMethodMatching

Becomes

supportedFeatures:
- name: HTTPRouteHostRewrite
- name: HTTPRouteMethodMatching

[LiorLieberman]

I agree that just a list is something we can and should improve but I think I am plus 1 to @kflynn's comment (as long as we can change the status api later)

I feel like we are doing nothing if we change it now without concrete feedback.

@arkodg just posted his thoughts here

Regarding implementations, we have istio and envoy-gw. I also talked with @mikemorris and @snehachhabria about Azure Application Gateway. But yes, we still need one more implementation.

Also, as discussed, you can add to the work required - to move the conformance tests to read from GWC so more implementations would want to implement that.

[LiorLieberman]

Scoping is by June 11th, when we aiming to release ?

[robscott]

if we pick the middle of each of the ranges in https://gateway-api.sigs.k8s.io/contributing/release-cycle/#2-gep-iteration-and-review, that would be 6 + 4 + 3 weeks, so 13 weeks from June 11, which is apparently September 10. Too early to commit to that specific date, but I think September is the goal

[LiorLieberman]

opened a dedicated issue for this #3164

[robscott]

BackendTLSPolicy (#1897)

Status:
Conformance: Not Started
Documentation: Mostly Complete
Implementations: 2/3

Work Required:

• Survey implementations to ensure we have enough (3+) and/or encourage more implementations to support this feature.
• Write conformance tests
• Updates to GEP, docs, and API types to bump status to standard.

Previous Leads:
@candita has led this effort.

[whitneygriffith]

@candita do you need help with the conformance tests? I'd love to work on it.

[whitneygriffith]

@robscott @youngnick does the #3138 plan for conformance testing suffice for this GEP to be merged as implementable for Standard?

[youngnick]

The plan seems pretty reasonable to me, probably want some thoughts from @mlavacca when he's back as well.

[mlavacca]

I left a couple of comments in #3138. I think the list is not only pretty complete, but some tests have to be removed from there (details in the issue).

[candita]

This did not make it to v1.2 Standard.

[robscott]

Backend Protocol Selection (#1911)

Status:
Conformance: In Progress
Documentation: In Progress
Implementations: ?/3

Work Required:

• Survey implementations to ensure we have enough (3+) and/or encourage more implementations to support this feature.
• Complete documentation and conformance (this may already be done)
• Updates to GEP, docs, and API types to bump status to standard.

Previous Leads:
@dprotaso has led this effort.

[dprotaso]

Supported implementations (passing h2c & websocket test)

• envoy gateway
• istio
• contour

[robscott]

TLSRoute (#2643)

Status:
Conformance: In Progress
Documentation: In Progress
Implementations: 4+/3

Work Required:

• Complete documentation and conformance
• TLSRoute predates GEPs, but it would be useful to have a basic one for this + to cover why we don't want to just reuse TCPRoute for passthrough
• Updates to GEP, docs, and API types to bump status to standard.

Previous Leads:
It's been many years, I'm not really sure at this point...

[ahmadalkhansa]

Hello, is tlsroute implemented in v1.3.0? If yes, I would eagerly install the related crd.

[mlavacca]

The plan is to graduate TLSRoute for 1.2. As a result, it will move from the experimental channel to the standard one. Can I ask you which implementation you are using/planning to use?

[ahmadalkhansa]

My apologies. I've been following the documentation of nginx-gateway-fabric v1.3.0 and it seems that their kustomization of the standard channel is pointing to the crd (https://github.com/kubernetes-sigs/gateway-api/tree/v1.1.0/config/crd/standard) of the standard channel. I think that I have to switch to the experimental channel. Extreme apologies for the confusion. Thank you and much appreciation for the great work that you are doing!!

[mlavacca]

Yeah no worries at all, @ahmadalkhansa! For the time being, if you want to use TLSRoutes you need to install the experimental channel of the CRDs. In case we'll manage to promote such an API for 1.2, they'll be available in the standard channel.

[candita]

This did not make it into release v1.2

[robscott]

In-Cluster Gateway Config (#1762)

Status:
Conformance: N/A
Documentation: Not Started
Implementations: ?/3

Work Required:

• Survey implementations to ensure we have enough (3+) and/or encourage more implementations to support this feature.
• Write documentation
• Updates to GEP, docs, and API types to bump status to standard.

Previous Leads:
@howardjohn led this to experimental status.

[mikemorris]

To be clear, is the scope for this just the spec.infrastructure stanza with annotations and labels keys?

[keithmattix]

Yep, that's my understanding

[mikemorris]

Okay I think the issue link for this isn't quite correct then and this should be tracking [the no-longer-quite-accurately-named] #1762 and GEP-1762 for those fields (which also includes some spec.addresses behavior with regard to an underlying Service resource and setting a well-known label on in-cluster resources generated by from a Gateway, which could actually help with "generated resources" flag mentioned in the meeting notes - just check for matching annotations and labels on all - zero or more - resources with a matching label).

#1867 and GEP-1867 track the prerequisite spec.infrastructure field (which we could roll in if we only want to target GEP-1762 with this effort) but importantly mostly focuses on adding spec.infrastructure.parametersRef to Gateway objects, which I'm unsure if we're ready to promote yet (would need to check implementations separately).

[robscott]

Good catch, thanks @mikemorris! I've updated the original comment to point to #1762.

[keithmattix]

/cc @whitneygriffith I think we're back in business w.r.t conformance