-
Notifications
You must be signed in to change notification settings - Fork 493
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
v1.1 API Review #2997
Conversation
Skipping CI for Draft Pull Request. |
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. |
/cc |
[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 |
// Support: Core | ||
// | ||
// +optional | ||
Namespace *Namespace `json:"namespace,omitempty"` |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
gateway-api/apis/v1/shared_types.go
Lines 598 to 601 in 12d50fe
// +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)" |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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"` |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is related to this https://github.com/grpc/proposal/blob/master/A55-xds-stateful-session-affinity.md 🧑🎓
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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"` |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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"` |
There was a problem hiding this comment.
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 ...
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. |
Formally closing this one out, thanks for the feedback on this! We'll be releasing v1.1 in another ~3 hours. |
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