api: experimental ResolvedRefs condition for Gateway #4195
Conversation
k8s-ci-robot
added
release-note
k8s-ci-robot
added
the
size/M
Signed-off-by: Norwin Schnyder <[email protected]>
snorwin
force-pushed
the
gateway-backend-tls-api
branch
from
11ba606 to
bc1e880
Compare
|
Nice work, thanks @snorwin. /approve |
k8s-ci-robot
added
the
approved
snorwin
force-pushed
the
gateway-backend-tls-api
branch
2 times, most recently
from
4856b7f to
0818f34
Compare
Signed-off-by: Norwin Schnyder <[email protected]>
snorwin
force-pushed
the
gateway-backend-tls-api
branch
from
0818f34 to
425d501
Compare
| // * It refers to a resource that cannot be resolved (e.g., the referenced resource | ||
| // does not exist) or is misconfigured (e.g., a Secret does not contain the keys | ||
| // named `tls.crt` and `tls.key`). In this case, the `ResolvedRefs` condition | ||
| // on the Gateway MUST be set to False with the Reason `InvalidClientCertificateRef` |
There was a problem hiding this comment.
I'm worried that Cx might confused this error with other TLS based features like ClientCertValidation, can we be more specifica about the certificate?
InvalidClientCertificateRef -> InvalidGatewayClientCertificateRef
There was a problem hiding this comment.
Wouldn't InvalidBackendClientCertificateRef be more accurate?
However, it is quite long, and since a Gateway only has one clientCertificateRef field, it should be clear which one is meant.
There was a problem hiding this comment.
InvalidBackendClientCertificateRef is not accurate because this is Gateway's certificate to communicate with Backends.
There was a problem hiding this comment.
For simplicity, I’d prefer to keep the reason as InvalidClientCertificateRef. Since it’s already set on the Gateway, adding Gateway to the reason feels redundant. But if there are better alternatives, I’m happy to adjust.
Signed-off-by: Norwin Schnyder <[email protected]>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kl52752, snorwin, youngnick 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 |
|
/lgtm |
k8s-ci-robot
added
the
lgtm
…#4195) * api: experimental ResolvedRefs condition for Gateway Signed-off-by: Norwin Schnyder <[email protected]> * add reason ListenersNotResolved Signed-off-by: Norwin Schnyder <[email protected]> * apply PR feedback Signed-off-by: Norwin Schnyder <[email protected]> --------- Signed-off-by: Norwin Schnyder <[email protected]>
4 participants
What type of PR is this?
/kind documentation
/kind feature
What this PR does / why we need it:
This PR follows up on #4123 to update the GoDoc comments and introduce a new GatewayConditionType constant of
ResolvedRefs, with associated Reason as its own GatewayConditionReason.Which issue(s) this PR fixes:
N/A
Does this PR introduce a user-facing change?: