You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// +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)"
What you expected to happen:
Similar to #2668, I believe this validation is unnecessarily strict and should be reverted.
Anything else we need to know?:
As I've been thinking about more TLS user stories for Gateway API, particularly self service and generated certs (#763 (comment)), I've realized that the strictness of our validation here has made it unnecessarily complex to handle some very real use cases. I think it is critical for our API to be flexible enough here to enable different personas to configure TLS.
When I pulled TLS Certs out of Routes, I still had every intention of enabling app owners to configure TLS Certs (thus #763 was created). Unfortunately I think we lost track of that goal when writing this specific validation.
Note the this is closely tied to #2668 and if we get consensus around this approach as well, I'll work on a change that incorporates reverting both validations + adding documentation and guidance for how implementations should handle the absence of these fields.
The text was updated successfully, but these errors were encountered:
What happened:
Our CEL validation currently requires that TLS config is specified on a Listener when the protocol is
HTTPS
orTLS
:gateway-api/apis/v1/gateway_types.go
Line 189 in 9a663ba
What you expected to happen:
Similar to #2668, I believe this validation is unnecessarily strict and should be reverted.
Anything else we need to know?:
As I've been thinking about more TLS user stories for Gateway API, particularly self service and generated certs (#763 (comment)), I've realized that the strictness of our validation here has made it unnecessarily complex to handle some very real use cases. I think it is critical for our API to be flexible enough here to enable different personas to configure TLS.
When I pulled TLS Certs out of Routes, I still had every intention of enabling app owners to configure TLS Certs (thus #763 was created). Unfortunately I think we lost track of that goal when writing this specific validation.
Note the this is closely tied to #2668 and if we get consensus around this approach as well, I'll work on a change that incorporates reverting both validations + adding documentation and guidance for how implementations should handle the absence of these fields.
The text was updated successfully, but these errors were encountered: