Skip to content

Conversation

shaneutt
Copy link
Member

This is a PR to gather some early initial feedback on the upcoming changes for #3756. It should not be merged.

LiorLieberman and others added 30 commits April 24, 2025 14:42
…s#3729)

* add mesh confomance tests structure and first test

* move mesh tests to mesh folder
kubernetes-sigs#3777)

* add redirect-port and redirect scheme mesh tests

* mesh tests for path host and status redirect
Signed-off-by: Norwin Schnyder <norwin.schnyder+github@gmail.com>
* Add conformance report for Contour 1.31.0

Supports gateway API 1.2.1

Signed-off-by: Sunjay Bhatia <sunjay.bhatia@broadcom.com>

* update implementations.md

Signed-off-by: Sunjay Bhatia <sunjay.bhatia@broadcom.com>

---------

Signed-off-by: Sunjay Bhatia <sunjay.bhatia@broadcom.com>
…3781)

* add csm mesh to implementations.md

* fix

* fix1

* Update implementations.md

Co-authored-by: Rob Scott <rob.scott87@gmail.com>

---------

Co-authored-by: Rob Scott <rob.scott87@gmail.com>
…igs#3564)

Add feature name processing to remove redundant prefixes and improve
readability in conformance comparison tables. Changes include:

- Remove "HTTPRoute" and "Gateway" prefixes from feature names
- Split camelCase words into space-separated words
- Add process_feature_name() function for consistent text processing
- Update generate_profiles_report() to use processed feature names

This makes the conformance reports easier to read
Signed-off-by: bitliu <bitliu@tencent.com>
…igs#3809)

* conformance: Add Airlock Microgateway report for v1.3.0

Signed-off-by: Norwin Schnyder <norwin.schnyder+github@gmail.com>

* add trailing new lines

Signed-off-by: Norwin Schnyder <norwin.schnyder+github@gmail.com>

---------

Signed-off-by: Norwin Schnyder <norwin.schnyder+github@gmail.com>
…#3811)

Signed-off-by: Norwin Schnyder <norwin.schnyder+github@gmail.com>
* conformance: add Hook in ConformanceTestSuite

* update comment

Signed-off-by: zirain <zirain2009@gmail.com>

* add Hook in ConformanceOptions

Signed-off-by: zirain <zirain2009@gmail.com>

---------

Signed-off-by: zirain <zirain2009@gmail.com>
)

This PR removes the Dependabot configuration for the `github-actions` package ecosystem since Github Actions are not used in this repository. There is no PR ever created with a `dependencies` tag which is not for `go`, `docker`, or `python`.
* add mesh conformance for request header modifier

* address feedback
* docs: Add v1.3 conformance report table

Signed-off-by: Norwin Schnyder <norwin.schnyder+github@gmail.com>

* Automatically update conformance table files

Signed-off-by: Norwin Schnyder <norwin.schnyder+github@gmail.com>

---------

Signed-off-by: Norwin Schnyder <norwin.schnyder+github@gmail.com>
Signed-off-by: Shane Utt <shaneutt@linux.com>
…-sigs#3827)

* add httproute weights mesh conformance tests

* gofmt
…#2712)

* draft dns configuration for gateway API GEP-2627

minor tweaks

Update geps/gep-2627/index.md

Co-authored-by: Candace Holman <candita@users.noreply.github.com>

Update geps/gep-2627/index.md

Co-authored-by: Candace Holman <candita@users.noreply.github.com>

Update geps/gep-2627/index.md

Co-authored-by: Candace Holman <candita@users.noreply.github.com>

* changes post review

* rewording

* Update geps/gep-2627/index.md

Co-authored-by: Nick Young <inocuo@gmail.com>

* Update geps/gep-2627/index.md

Co-authored-by: Nick Young <inocuo@gmail.com>

* Update geps/gep-2627/index.md

Co-authored-by: Nick Young <inocuo@gmail.com>

* Update geps/gep-2627/index.md

Co-authored-by: Nick Young <inocuo@gmail.com>

* Update geps/gep-2627/index.md

Co-authored-by: Shane Utt <shane@shaneutt.com>

* Update geps/gep-2627/index.md

Co-authored-by: Shane Utt <shane@shaneutt.com>

* Update geps/gep-2627/index.md

Co-authored-by: Shane Utt <shane@shaneutt.com>

* Update geps/gep-2627/index.md

Co-authored-by: Shane Utt <shane@shaneutt.com>

* Update geps/gep-2627/index.md

Co-authored-by: Shane Utt <shane@shaneutt.com>

* Update geps/gep-2627/index.md

Co-authored-by: Shane Utt <shane@shaneutt.com>

* Update geps/gep-2627/index.md

Co-authored-by: Shane Utt <shane@shaneutt.com>

* Update geps/gep-2627/index.md

Co-authored-by: Shane Utt <shane@shaneutt.com>

* minor tweaks to the text and link to kuadrant as an example of a DNSPolicy type API

* fix new line

* move kuadrant to a reference

---------

Co-authored-by: Candace Holman <candita@users.noreply.github.com>
Co-authored-by: Nick Young <inocuo@gmail.com>
Co-authored-by: Shane Utt <shane@shaneutt.com>
Signed-off-by: Keith Mattix II <keithmattix@microsoft.com>
* Kubevernor conformance report

* Adding Kubvernor section to implementations section
Adding conformance report for the v2.0 NGINX Gateway Fabric release. Now supporting Gateway API v1.3.
@shaneutt shaneutt added the do-not-merge DEPRECATED. Indicates that a PR should not merge. Label can only be manually applied/removed. label Aug 28, 2025
@k8s-ci-robot
Copy link
Contributor

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
Copy link
Contributor

Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

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.

@k8s-ci-robot k8s-ci-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. do-not-merge/invalid-commit-message Indicates that a PR should not merge because it has an invalid commit message. labels Aug 28, 2025
@k8s-ci-robot
Copy link
Contributor

Keywords which can automatically close issues and at(@) or hashtag(#) mentions are not allowed in commit messages.

The list of commits with invalid commit messages:

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.

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: 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:

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

@k8s-ci-robot k8s-ci-robot added the kind/gep PRs related to Gateway Enhancement Proposal(GEP) label Aug 28, 2025
@k8s-ci-robot k8s-ci-robot added approved Indicates a PR has been approved by an approver from all required OWNERS files. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Aug 28, 2025
@shaneutt shaneutt requested review from robscott, youngnick, mlavacca, danwinship, aojea and bowei and removed request for howardjohn and LiorLieberman August 28, 2025 12:28
@shaneutt shaneutt moved this to Review in Release v1.4.0 Aug 28, 2025
// +kubebuilder:validation:Minimum=1
// +kubebuilder:validation:Maximum=65535
// <gateway:experimental>
Port PortNumber `json:"port"`
Copy link
Contributor

@aojea aojea Aug 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we had this questions in the review of GIE, right now everything is HTTP1 and HTTP2 that are TCP , but eventually we'll get to http3 that is UDP :/ and this will require to discriminate by port ... and then the key need to be Port+proto ... just commenting

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Handling HTTP3 correctly will require a lot of changes , I guess we should add this to the pile. Thanks!

// FrontendTLSConfig specifies frontend tls configuration for gateway.
type FrontendTLSConfig struct {
// Default specifies the default client certificate validation configuration
// for all Listeners handling HTTPS traffic, unless a per-port configuration
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just for my understanding, this field is required, so the unless a per-port configuration means if a Port configuration exists it overrides the default, but is not that this is a kind of oneOf API, you always need to define a default?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question, I don't think we defined what happens if you don't set a default and do set a per-port config. We either need to say you can't do that, or define what happens when you do.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aojea yes :)
After all review rounds we agreeded that per port override rules might be confusing. Therefore, a default option is required and will apply to all Listeners with HTTPS protocol. If someone needs to divers frontend TLS config then it can be overridden for a specific port if needed.

//
// References to a resource in a different namespace are invalid UNLESS there
// is a ReferenceGrant in the target namespace that allows the certificate
// to be attached. If a ReferenceGrant does not allow this reference, the
// "ResolvedRefs" condition MUST be set to False for this listener with the
// "RefNotPermitted" reason.
//
// +required
// +listType=atomic
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TIL default is atomic kubernetes/kubernetes#121759 , I'm educating myself here, is that right @thockin ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep - kube-api-linter is requiring us to specify in all cases, even though this is the default. It's easy to forget to set this and accidentally end up with atomic, so I think this is a net positive.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, explicit > implicit :)

// if relevant.)
//
// </gateway:util:excludeFromCRD>
//
// +listType=map
// +listMapKey=type
// +kubebuilder:validation:MaxItems=8
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question, I see in some places you require one item

// +listType=map
// +listMapKey=type
// +kubebuilder:validation:MinItems=1
// +kubebuilder:validation:MaxItems=8
// +required
Conditions []metav1.Condition `json:"conditions,omitempty"`

is this allowed to have empty or you always want to have at least 1?

	// +kubebuilder:validation:MinItems=1

Comment on lines +1668 to +1676
// If this list is empty, then the following headers must be sent:
//
// - `Authorization`
// - `Location`
// - `Proxy-Authenticate`
// - `Set-Cookie`
// - `WWW-Authenticate`
//
// If the list has entries, only those entries must be sent.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not default the list to these if empty?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This brings up, to me, an ambiguity in the spec.

If the list is empty, does the proxy need to send exactly these 5 headers and nothing else? Or at least these 5, and the rest is implementation specific?

If the former, how can I say "send all headers", which is (IIUC) the most common usage with grpc?

If the latter, why not just default to all headers?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I based this on the protos at https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/ext_authz/v3/ext_authz.proto#envoy-v3-api-msg-extensions-filters-http-ext-authz-v3-extauthz, but on rereading, them, I've made a mistake.

The gRPC header config should be as @howardjohn says - if unspecified or empty, then all headers should be sent. Those five headers are relevant for the HTTP external servers, not the gRPC one.

I'll make a PR to fix this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, actually, looking back, @kflynn asked for this list to be included (in #3884 (comment)), so I think that he should have the chance to respond here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking back over my comments and rereading, I'm pretty sure that I was unclear in my original comment. It's critical that HTTP not send all headers, ever. For gRPC, the implementations I know of just send all the headers because it's safe to do so.

Sorry for the confusion and thanks for doublechecking, @youngnick!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to fully close the loop on this and be explicit -- I agree with Flynn that HTTP=subset, gRPC=all is the correct default here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, great, I will make a PR to change this today.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opened #4061 with changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. do-not-merge/invalid-commit-message Indicates that a PR should not merge because it has an invalid commit message. do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. do-not-merge DEPRECATED. Indicates that a PR should not merge. Label can only be manually applied/removed. kind/gep PRs related to Gateway Enhancement Proposal(GEP) size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
Status: Review
Development

Successfully merging this pull request may close these issues.