-
Notifications
You must be signed in to change notification settings - Fork 472
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
Removing BackendPolicy #732
Removing BackendPolicy #732
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: robscott 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 |
// AnnotationAppProtocol defines the protocol a Gateway should use for | ||
// communication with a Kubernetes Service. This annotation must be present | ||
// on the BackendPolicy resource and the protocol will apply to all Service | ||
// ports that are selected by BackendPolicy.Spec.BackendRefs. If the | ||
// AppProtocol field is available, this annotation should not be used. The | ||
// AppProtocol field, when populated, takes precedence over this annotation. | ||
// The value of this annotation must be also be a valid value for the | ||
// AppProtocol field. | ||
// | ||
// Examples: | ||
// | ||
// - `gateway.networking.k8s.io/app-protocol: https` | ||
// - `gateway.networking.k8s.io/app-protocol: tls` | ||
AnnotationAppProtocol = "gateway.networking.k8s.io/app-protocol" |
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.
This is a significant removal, but given that Kubernetes 1.18+ is so widely used already, I don't think it's worth including workarounds for older Kubernetes versions anymore. Since this one depended on BackendPolicy, it would be difficult to recreate without some kind of intermediate resource.
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 opened up #737 to track the versions we support.
I was ambivallent about the change but given where we are and where this API is, reworking this in won't have much ROI.
+1
route. | ||
|
||
```yaml | ||
{% include 'upstream-tls.yaml' %} |
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.
Please delete this file.
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.
To clarify, this is just the upstream-tls example right? In that case, it's still used by v1alpha1 docs, and probably will be as long as we keep v1alpha1 docs around.
/lgtm /hold because:
|
resource. | ||
|
||
Please note that the TLS configuration is related to the Service or backend | ||
resource and not related to a specific route resource. |
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.
Can we keep some of this text and inform the user to use ReferencePolicy for these purposes? it could help with some education and getting our users and implementers be more aware about the new feature.
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 that the Policy Attachment GEP is likely a better fit here, though it will be easier to reference that when #736 merges.
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.
Added a hold on #736 to deal with this there.
This is part of the GEP kubernetes-sigs#713 implementation.
e6df69b
to
80e72bd
Compare
/lgtm |
Removing the hold on this one since I think we already have clear consensus on the GEP that proposed this. /hold cancel |
What type of PR is this?
/kind cleanup
/kind api-change
What this PR does / why we need it:
This is part of the GEP #713 implementation.
Does this PR introduce a user-facing change?: