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
* Add conformance report for Contour 1.31.0

Supports gateway API 1.2.1

Signed-off-by: Sunjay Bhatia <[email protected]>

* update implementations.md

Signed-off-by: Sunjay Bhatia <[email protected]>

---------

Signed-off-by: Sunjay Bhatia <[email protected]>
…3781)

* add csm mesh to implementations.md

* fix

* fix1

* Update implementations.md

Co-authored-by: Rob Scott <[email protected]>

---------

Co-authored-by: Rob Scott <[email protected]>
…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
…igs#3809)

* conformance: Add Airlock Microgateway report for v1.3.0

Signed-off-by: Norwin Schnyder <[email protected]>

* add trailing new lines

Signed-off-by: Norwin Schnyder <[email protected]>

---------

Signed-off-by: Norwin Schnyder <[email protected]>
* conformance: add Hook in ConformanceTestSuite

* update comment

Signed-off-by: zirain <[email protected]>

* add Hook in ConformanceOptions

Signed-off-by: zirain <[email protected]>

---------

Signed-off-by: zirain <[email protected]>
)

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 <[email protected]>

* Automatically update conformance table files

Signed-off-by: Norwin Schnyder <[email protected]>

---------

Signed-off-by: Norwin Schnyder <[email protected]>
…-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 <[email protected]>

Update geps/gep-2627/index.md

Co-authored-by: Candace Holman <[email protected]>

Update geps/gep-2627/index.md

Co-authored-by: Candace Holman <[email protected]>

* changes post review

* rewording

* Update geps/gep-2627/index.md

Co-authored-by: Nick Young <[email protected]>

* Update geps/gep-2627/index.md

Co-authored-by: Nick Young <[email protected]>

* Update geps/gep-2627/index.md

Co-authored-by: Nick Young <[email protected]>

* Update geps/gep-2627/index.md

Co-authored-by: Nick Young <[email protected]>

* Update geps/gep-2627/index.md

Co-authored-by: Shane Utt <[email protected]>

* Update geps/gep-2627/index.md

Co-authored-by: Shane Utt <[email protected]>

* Update geps/gep-2627/index.md

Co-authored-by: Shane Utt <[email protected]>

* Update geps/gep-2627/index.md

Co-authored-by: Shane Utt <[email protected]>

* Update geps/gep-2627/index.md

Co-authored-by: Shane Utt <[email protected]>

* Update geps/gep-2627/index.md

Co-authored-by: Shane Utt <[email protected]>

* Update geps/gep-2627/index.md

Co-authored-by: Shane Utt <[email protected]>

* Update geps/gep-2627/index.md

Co-authored-by: Shane Utt <[email protected]>

* 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 <[email protected]>
Co-authored-by: Nick Young <[email protected]>
Co-authored-by: Shane Utt <[email protected]>
* 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 do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. do-not-merge DEPRECATED. Indicates that a PR should not merge. Label can only be manually applied/removed. labels 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.

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.