Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v1.1 API Review #2997

Closed
wants to merge 1 commit into from
Closed

Conversation

robscott
Copy link
Member

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

What this PR does / why we need it:
This PR is a diff of /apis from v1.1 (main branch) to v1.0 (release-1.0 branch). I've made one change - excluding the added generated applyconfigurations because they would add a lot of noise.

Note: This PR is purely to facilitate review, it is not intended to merge.

Does this PR introduce a user-facing change?:
See #2967

/assign @aojea @danwinship @thockin

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

@k8s-ci-robot k8s-ci-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Apr 19, 2024
@k8s-ci-robot k8s-ci-robot added kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. 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. labels Apr 19, 2024
@k8s-ci-robot k8s-ci-robot requested review from bowei and thockin April 19, 2024 16:44
@shaneutt
Copy link
Member

/cc

@k8s-ci-robot k8s-ci-robot requested a review from shaneutt April 19, 2024 20:21
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

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

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

// Support: Core
//
// +optional
Namespace *Namespace `json:"namespace,omitempty"`
Copy link
Contributor

@aojea aojea Apr 24, 2024

Choose a reason for hiding this comment

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

a namespace with an empty name, namespace = "" is an error or is not even possible?

Copy link
Member Author

Choose a reason for hiding this comment

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

We use type aliases heavily for common validation, including in this case. So nil is valid (pointer type) but "" is not.

// +kubebuilder:validation:Pattern=`^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`
// +kubebuilder:validation:MinLength=1
// +kubebuilder:validation:MaxLength=63
type Namespace string

@@ -186,8 +187,8 @@ type GatewaySpec struct {
// +listMapKey=name
// +kubebuilder:validation:MinItems=1
// +kubebuilder:validation:MaxItems=64
// +kubebuilder:validation:XValidation:message="tls must be specified for protocols ['HTTPS', 'TLS']",rule="self.all(l, l.protocol in ['HTTPS', 'TLS'] ? has(l.tls) : true)"
Copy link
Contributor

Choose a reason for hiding this comment

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

is this no longer required?

Copy link
Contributor

Choose a reason for hiding this comment

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

I see is explained here #2721

// Support: Extended
//
// +optional
AbsoluteTimeout *Duration `json:"absoluteTimeout,omitempty"`
Copy link
Contributor

@aojea aojea Apr 24, 2024

Choose a reason for hiding this comment

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

is 0s allowed? it should not (I guess)

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep, it's a common way to disable timeouts in proxy implementations - x-ref #3012

//
// +optional
// <gateway:experimental>
SessionPersistence *SessionPersistence `json:"sessionPersistence"`
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep, Sanjay and Gina from gRPC team were helping with this Gateway API proposal.

// in different namespaces. For more information on how this policy attachment
// model works, and a sample Policy resource, refer to the policy attachment
// documentation for Gateway API.
type NamespacedPolicyTargetReference struct {
Copy link
Contributor

Choose a reason for hiding this comment

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

AFAIK this is not referenced elsewhere , only in this gwctl tool, is that correct?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep, it's part of the types that we encourage policy extensions to use, but not used internally.

Copy link
Contributor

Choose a reason for hiding this comment

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

We've discussed that this type may be useful for mesh policies in the future, such as applying client-side policy for outbound connections from a pod to a destination in another namespace.

//
// +optional
WellKnownCACerts *WellKnownCACertType `json:"wellKnownCACerts,omitempty"`
WellKnownCACertificates *WellKnownCACertificatesType `json:"wellKnownCACertificates,omitempty"`
Copy link
Contributor

@aojea aojea Apr 24, 2024

Choose a reason for hiding this comment

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

Who defines this list of WellKnownCA certiticates? is it implementation specific?

My specific question is if 2 different implementations that set this field to System can have different lists

Copy link
Member Author

Choose a reason for hiding this comment

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

yep, implementation specific, we should probably make this more clear. In many/most cases, this will depend on something like https://packages.debian.org/sid/ca-certificates being used by the Gateway, but there are lots of variations of what is trusted, or some may even choose to inject their own well known CA certs to a controller container to have them considered as "system", all of this is inherently implementation specific though.

Copy link
Contributor

Choose a reason for hiding this comment

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

ok, is clarified in the documentation

There may be some variation in which system certificates are used by each implementation. Refer to documentation from your implementation of choice for more information.

// Support: Extended
//
// +optional
SessionPersistence *SessionPersistence `json:"sessionPersistence"`
Copy link
Contributor

Choose a reason for hiding this comment

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

talked offline with Rob, LB and SessionPersistence can mean a lot of things , specially depending at what layer of the LB we are talking ...

@robscott
Copy link
Member Author

robscott commented May 6, 2024

Thanks to everyone (@aojea, @danwinship, @thockin) for the feedback on this both on the PR and in our review meeting. We've released RC1 and RC2 and are planning to move forward with this release on Wednesday, May 9. Please get any remaining feedback in ASAP. We'll plan on closing out this PR and the formal review process ~24 hours from now.

@robscott
Copy link
Member Author

robscott commented May 8, 2024

Formally closing this one out, thanks for the feedback on this! We'll be releasing v1.1 in another ~3 hours.

@robscott robscott closed this May 8, 2024
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/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. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants